[issue6630] string.Template custom pattern not working
New submission from Javier : In the string.Template documentation (http://docs.python.org/library/string.html) it's explained that if a custom regular expression for pattern substitution is needed, it's possible to override idpattern class attribute (whose default value is [_a-z][_a-z0-9]*). However, if the custom pattern that is needed is just uppercase letters, something like [A-Z]+ won't work because of the following line in the _TemplateMetaclass class __init__ method: cls.pattern = _re.compile(pattern, _re.IGNORECASE | _re.VERBOSE) I would say that this is an error (IGNORECASE just shouldn't be there) and that the line above should be: cls.pattern = _re.compile(pattern, _re.VERBOSE) and the default value for idpattern: [_a-zA-Z][_a-zA-Z0-9]* Do you agree on this? Is there any reason for the IGNORECASE option to be passed to re.compile? -- components: IO, Regular Expressions messages: 91217 nosy: jcollado severity: normal status: open title: string.Template custom pattern not working type: behavior versions: Python 2.6, Python 3.0 ___ Python tracker <http://bugs.python.org/issue6630> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
New submission from Javier :
What steps will reproduce the problem?
1. Run 'python subcommands.py -h' (attached file)
2. Check the ordering of the subcommands in the output:
subcommands:
{a,c,b,e,d}
a a subcommand help
b b subcommand help
c c subcommand help
d d subcommand help
e e subcommand help
The ordering between brackets is different than the ordering in the one-line
help for each command below. This could be a little confusing to the user.
What is the expected output? What do you see instead?
The expected output would be to use the same ordering in both places. In
particular the same ordering that was used in the code when using the
_SubParsersAction.add_parser method:
subcommands:
{a,b,c,d,e}
a a subcommand help
b b subcommand help
c c subcommand help
d d subcommand help
e e subcommand help
What version of the product are you using? On what operating system?
OS: Ubuntu
Version: source code (rev. 87)
Python: 2.6.5
Please provide any additional information below.
Please have a look at the attached diff. It contains a patch that worked for me
to preserve the ordering used in the code.
To make that possible it uses action._choices_actions (a list) instead of
action.choices (a dictionary).
--
components: Library (Lib)
files: subcommands.py
messages: 108096
nosy: jcollado
priority: normal
severity: normal
status: open
title: [argparse] Subcommands not printed in the same order they were added
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17704/subcommands.py
___
Python tracker
<http://bugs.python.org/issue9026>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
Javier added the comment: It contains a patch that worked for me to preserve the ordering used in the code. To make that possible it uses action._choices_actions (a list) instead of action.choices (a dictionary). -- keywords: +patch Added file: http://bugs.python.org/file17705/ordered_subcommands.diff ___ Python tracker <http://bugs.python.org/issue9026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
Javier added the comment: While the ordered dict is a nice option, the one-line patch that is attached to the report works in python < 2.7 without adding any external dependency. In my opininion, that's interesting for those using argparse with earlier versions of python. -- ___ Python tracker <http://bugs.python.org/issue9026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3821] trace module bug when using --missing
New submission from Juan Javier <[EMAIL PROTECTED]>: I get the following exception: $ /opt/python3.0b2/bin/python3.0 -m trace -c -m run.py Traceback (most recent call last): File "/opt/python3.0b2/lib/python3.0/runpy.py", line 121, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/opt/python3.0b2/lib/python3.0/runpy.py", line 34, in _run_code exec(code, run_globals) File "/opt/python3.0b2/lib/python3.0/trace.py", line 809, in main() File "/opt/python3.0b2/lib/python3.0/trace.py", line 806, in main results.write_results(missing, summary=summary, coverdir=coverdir) File "/opt/python3.0b2/lib/python3.0/trace.py", line 303, in write_results lnotab = find_executable_linenos(filename) File "/opt/python3.0b2/lib/python3.0/trace.py", line 428, in find_executable_linenos return find_lines(code, strs) File "/opt/python3.0b2/lib/python3.0/trace.py", line 392, in find_lines linenos.update(find_lines(c, strs)) File "/opt/python3.0b2/lib/python3.0/trace.py", line 386, in find_lines linenos = find_lines_from_code(code, strs) File "/opt/python3.0b2/lib/python3.0/trace.py", line 370, in find_lines_from_code line_increments = [ord(c) for c in code.co_lnotab[1::2]] File "/opt/python3.0b2/lib/python3.0/trace.py", line 370, in line_increments = [ord(c) for c in code.co_lnotab[1::2]] TypeError: ord() expected string of length 1, but int found I think that line 370 of trace.py should say: line_increments = [int(c) for c in code.co_lnotab[1::2]] instead of: line_increments = [ord(c) for c in code.co_lnotab[1::2]] -- components: Library (Lib) messages: 72879 nosy: jjdominguezm severity: normal status: open title: trace module bug when using --missing versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3821> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1916] Add inspect.isgenerator
Javier Mansilla added the comment:
I merged my working copy with your patches and they look fine. I fixed a
typo on the method doc ("is" instead of "i") so I'm attaching my
inspect.py.diff patch
--
nosy: +javimansilla
Added file: http://bugs.python.org/file9444/test_inspect.py.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1916>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1916] Add inspect.isgenerator
Javier Mansilla added the comment: Sorry, I attached the wrong file The previous post saying "fixing typo" should attached inspect.py.diff. This is the one. Added file: http://bugs.python.org/file9445/test_inspect.py.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1916> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1916] Add inspect.isgenerator
Javier Mansilla added the comment: My dear, what is wrong with my browser (or with me). Now, yes, the one with the typo. Added file: http://bugs.python.org/file9446/inspect.py.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1916> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1916] Add inspect.isgenerator
Javier Mansilla added the comment: And now I'm attaching a new patch test_inspect.py.diff with a more complete test coverage. You didn't add isgenerator nor isgeneratorfunction tests. I did. Added file: http://bugs.python.org/file9447/test_inspect.py.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1916> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42004] Allow uploading files with SimpleHTTPRequestHandler
New submission from Javier Ayres : Hello. I'm a big fan of the http.server module to quickly serve some files in a local network with `python3 -m http.server`. I regularly needed to get some files from other people too, but getting everyone to install/run python3 was not such a simple task. Eventually I wrote a subclass of SimpleHTTPRequestHandler that added a form with a file input and accepted POST requests, so people could also upload files to my computer. I think this would be a fine addition to SimpleHTTPRequestHandler, so I'm attaching a potential patch that implements this and adds a new cli parameter so this feature is only enabled explicitly. -- components: Library (Lib) files: patch messages: 378418 nosy: lufte priority: normal severity: normal status: open title: Allow uploading files with SimpleHTTPRequestHandler type: enhancement versions: Python 3.10 Added file: https://bugs.python.org/file49506/patch ___ Python tracker <https://bugs.python.org/issue42004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42004] Allow uploading files with SimpleHTTPRequestHandler
Javier Ayres added the comment: I see. To be honest I didn't know FieldStorage at all, it was the best way I found of dealing with file data in requests using just the standard library. If you think this feature makes sense and it could be included, I could look into removing the FieldStorage dependency. -- ___ Python tracker <https://bugs.python.org/issue42004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
New submission from Juan Javier : Hello, This is a proposal to make the state of Future objects public. The idea is to have access to the current state of the Future using a property instead of calling several methods (done, cancelled, etc.). Also, a history property that returns a list of Event(state, timestamp) objects is written, the list stores the timestamp every time the state of a future changes. There is a patch attached to the issue. Regards. -- components: Library (Lib) files: concurrent.futures.Future.state_public.patch keywords: patch messages: 151259 nosy: bquinlan, jjdominguezm priority: normal severity: normal status: open title: Make concurrent.futures.Future state public type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file24237/concurrent.futures.Future.state_public.patch ___ Python tracker <http://bugs.python.org/issue13785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Juan Javier added the comment: Hello, You're right, explaining the difference between CANCELLED and CANCELLED_AND_NOTIFIED is gong to be hard and might be confusing. I also agree that there is no precedent for storing the history of something, and I don't like either the idea of having a futures factory (that was my first idea). But, what about using callbacks? it is possible to add done callbacks, why can't we have a list of callbacks attached to each "public" state. Something like: Future.append_callback(self, state: "One of PENDING, RUNNING, CANCELLED, FINISHED", fn) -- ___ Python tracker <http://bugs.python.org/issue13785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13978] OSError exception in multiprocessing module when using os.remove() on NFS
New submission from Javier Jardón : I have this little test case: import multiprocessing manager = multiprocessing.Manager() del manager and I get this: Traceback (most recent call last): File "/usr/lib/python2.7/multiprocessing/util.py", line 261, in _run_finalizers finalizer() File "/usr/lib/python2.7/multiprocessing/util.py", line 200, in __call__ res = self._callback(*self._args, **self._kwargs) File "/usr/lib/python2.7/shutil.py", line 249, in rmtree onerror(os.remove, fullname, sys.exc_info()) File "/usr/lib/python2.7/shutil.py", line 247, in rmtree os.remove(fullname) OSError: [Errno 16] Device or resource busy: '/nfs/tmp/pymp-f7R9S6/.nfse039692f0236' (the TMDIR directory is in a nfs server) -- components: Extension Modules messages: 152972 nosy: jjardon priority: normal severity: normal status: open title: OSError exception in multiprocessing module when using os.remove() on NFS type: crash versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue13978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Juan Javier added the comment: The use case is to know the state of a future without having to do something like this @property def state(self): if self.future.running(): return Process.States.Running elif self.future.cancelled(): return Process.States.Cancelled elif self.future.done(): return Process.States.Done return Process.States.Pending -- ___ Python tracker <http://bugs.python.org/issue13785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Juan Javier added the comment: I'm writting an application where users can submit long running jobs and I want to disply a list of those jobs and the state of each one. My idea is to use an executor and use the futures to display information about the jobs: not started, cancelled, running, etc. Think of a table with these headers: ID, Start date, Last state change date, State, Info -- ___ Python tracker <http://bugs.python.org/issue13785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30678] Widget variable binding does not work if mainloop is called from a different function
New submission from Javier Dehesa: When you build a Tkinter interface with variables, if tkinter.Tk.mainloop is called from a different function that the one creating the variable objects, then in some cases the widgets associated with the variables will not be set to the right value. I have not been able to find a consistent pattern, but I have some examples. The following script works correctly: ``` import tkinter as tk from tkinter import ttk def make_var_cb(root): v = tk.BooleanVar(root, True) cb = ttk.Checkbutton(root, text='Checkbutton', variable=v) cb.pack() root.mainloop() if __name__ == '__main__': root = tk.Tk() make_var_cb(root) ``` But the following does not (the result is shown in the attached image): ``` import tkinter as tk from tkinter import ttk def make_var_cb(root): v = tk.BooleanVar(root, True) cb = ttk.Checkbutton(root, text='Checkbutton', variable=v) cb.pack() if __name__ == '__main__': root = tk.Tk() make_var_cb(root) root.mainloop() ``` However, the following _does_ work again: ``` def make_var(root): return tk.BooleanVar(root, True) def make_cb(root, v): return ttk.Checkbutton(root, text='Checkbutton', variable=v) if __name__ == '__main__': root = tk.Tk() v = make_var(root) cb = make_cb(root, v) cb.pack() root.mainloop() ``` -- components: Tkinter, Windows files: checkbutton_bad.png messages: 296100 nosy: Javier Dehesa, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Widget variable binding does not work if mainloop is called from a different function type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file46954/checkbutton_bad.png ___ Python tracker <http://bugs.python.org/issue30678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30678] Widget variable binding does not work if mainloop is called from a different function
Javier Dehesa added the comment: Note, this is not something specific to check buttons, the same happens with other widgets such as entries. -- ___ Python tracker <http://bugs.python.org/issue30678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30678] Widget variable binding does not work if mainloop is called from a different function
Javier Dehesa added the comment: Yeah is quite subtle, I should have pointed it out... The difference is that `root.mainloop()` is called inside `make_var_cb(root)` in the first example and under `if __name__ == '__main__'` in the second one. I have experience the problem on Windows 10, and I'd say there is a good chance it's a platform-specific thing... -- ___ Python tracker <http://bugs.python.org/issue30678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30678] Widget variable binding does not work if mainloop is called from a different function
Javier Dehesa added the comment: I see what you mean. Looking at TkDocs (not sure if this is an "official" or "officially endorsed" source or not), one of the Python examples in the "Tk Concepts" section (http://www.tkdocs.com/tutorial/concepts.html) says: > Whether or not you save the widget object in a variable is entirely up to > you, and depends of course whether you'll need to refer to it later. Because > the object is inserted into the widget hierarchy, it won't be garbage > collected even if you don't keep your own reference to it. However, it very much looks like it may be related to what you said. -- ___ Python tracker <http://bugs.python.org/issue30678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30678] Widget variable binding does not work if mainloop is called from a different function
Javier Dehesa added the comment: With the additional hint of garbage collection I have found now a number of examples of this behaviour (e.g. https://stackoverflow.com/questions/7439432/python-themed-tkinter-entry-variable-will-not-set). However, I haven't found actual documentation warning of this, so I'm not sure if this is really expected or just something people has gotten used to live with. One could argue that you normally wouldn't need a variable in the first place if you are not keeping a reference to it, but I'm not sure what is the benefit of having a (I assume) weak reference in the widget. Maybe there are solid technical reasons but, from what I have seen, it seems to have caused more than one confusion. -- ___ Python tracker <http://bugs.python.org/issue30678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33214] join method for list and tuple
New submission from Javier Dehesa : It is pretty trivial to concatenate a sequence of strings: ''.join([str1, str2, ...]) Concatenating a sequence of lists is for some reason significantly more convoluted. Some current options include: sum([lst1, lst2, ...], []) [x for y [lst1, lst2, ...] for x in y] list(itertools.chain(lst1, lst2, ...)) The first one being the less recomendable but more intuitive and the third one being the faster but most cumbersome (see https://stackoverflow.com/questions/49631326/why-is-itertools-chain-faster-than-a-flattening-list-comprehension ). None of these looks like "the one obvious way to do it" to me. Furthermore, I feel a dedicated concatenation method could be more efficient than any of these approaches. If we accept that ''.join(...) is an intuitive idiom, why not provide the syntax: [].join([lst1, lst2, ...]) And while we are at it: ().join([tpl1, tpl2, ...]) Like with str, these methods should only accept sequences of objects of their own class (e.g. we could do [].join(list(s) for s in seqs) if seqs contains lists, tuples and generators). The use case for non-empty joiners would probably be less frequent than for strings, but it also solves a problem that has no clean solution with the current tools. Here is what I would probably do to join a sequence of lists with [None, 'STOP', None]: lsts = [lst1, lst2, ...] joiner = [None, 'STOP', None] lsts_joined = list(itertools.chain.from_iterable(lst + joiner for lst in lsts))[:-len(joiner)] Which is awful and inefficient (I am not saying this is the best or only possible way to solve it, it is just what I, self-considered experienced Python developer, might write). -- components: Library (Lib) messages: 314881 nosy: Javier Dehesa priority: normal severity: normal status: open title: join method for list and tuple type: enhancement ___ Python tracker <https://bugs.python.org/issue33214> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33214] join method for list and tuple
Javier Dehesa added the comment: Thanks Christian. I thought of join precisely because it performs conceptually the same function as with str, so the parallel between ''.join(), [].join() and ().join() looked more obvious. Also there is os.path.join and PurePath.joinpath, so the verb seemed well-established. As for shared method names, index and count are present both in sequences and str - although it is true that these do return the same kind of object in any cases. I'm not saying your points aren't valid, though. Your proposed way with extend is I guess about the same as list(itertools.chain(...)), which could be considered to be enough. I just feel that is not particularly convenient, especially for newer developers, which will probably gravitate towards sum(...) more than itertools or a nested generator expression, but I may be wrong. -- ___ Python tracker <https://bugs.python.org/issue33214> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34719] Deprecate set to frozenset conversion in set.__contains__
New submission from Javier Dehesa :
This comes from this SO question: https://stackoverflow.com/q/52382983/1782792
Currently, this works:
> print({1, 2} in {frozenset({1, 2}))
# True
This is strange because set is unhashable. Apparently, it is a case-specific
feature implemented back in 2003
(https://github.com/python/cpython/commit/19c2d77842290af9b5f470c1eea2a71d1f77c9fe),
by which set objects are converted to frozensets when checking for membership
in another set. Personally I feel this is a bit surprising and inconsistent,
but that is not the only issue with it. In the original implementation, this
conversion was basically free because the created frozenset used the same
storage as the given one. In the current implementation, however
(https://github.com/python/cpython/blob/3.7/Objects/setobject.c#L1888-L1906), a
new frozenset object is created, copied from the previous one. It seems this
was done for thread-safety. The problem with that is that it is significantly
more expensive:
s = set(range(10))
sf = frozenset(s)
t = { sf }
%timeit sf in t # True
>>> 31.6 ns ± 1.04 ns per loop (mean ± std. dev. of 7 runs, 1000 loops
each)
%timeit s in t # True
>>> 4.9 ms ± 168 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
In the above case, using the conversion takes five order of magnitude more time
than the regular check. I suppose there is a memory impact too.
I think this (as far as I know) undocumented feature does not provide a
significant usability gain, is inconsistent with the documented behavior of set
and gives rise to obscurely underperfoming code. Removing it would be a
breaking change, but again, affected code would be relying on undocumented
behavior (or even "against-documentation" behavior).
--
components: Interpreter Core
messages: 325631
nosy: Javier Dehesa
priority: normal
severity: normal
status: open
title: Deprecate set to frozenset conversion in set.__contains__
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue34719>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Changes by Juan Javier : -- status: open -> languishing ___ Python tracker <http://bugs.python.org/issue13785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Juan Javier added the comment: I totally agree, I'm going to take a look at the code and I'll write back with some comments. That will be next week, work is currently very demanding. -- status: languishing -> open versions: +Python 3.4 -Python 3.3 ___ Python tracker <http://bugs.python.org/issue13785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15634] synchronized decorator for the threading module
New submission from Juan Javier: I think it will be useful to have a decorator like this one on the threading module: def synchronized(func): """A decorator to make a function execution synchronized. Examples: @synchronized def foo(): pass class Foo: def __init__(self): self.__syncdata = None @property def syncdata(self): return self.__syncdata @syncdata.setter @synchronized def syncdata(self, value): self.__syncdata = value """ if not hasattr(func, "__lock"): func.__lock = threading.Lock() def _synchronized(*args, **kwds): with func.__lock: func(*args, **kwds) _synchronized.__doc__ = func.__doc__ return _synchronized What do you think? -- components: Library (Lib) messages: 168071 nosy: jjdominguezm priority: normal severity: normal status: open title: synchronized decorator for the threading module type: enhancement versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue15634> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15634] synchronized decorator for the threading module
Juan Javier added the comment: Ok, you are right, serialized is the right name. Also, passing the lock to the decorator will the correct option. -- ___ Python tracker <http://bugs.python.org/issue15634> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15634] synchronized decorator for the threading module
Juan Javier added the comment: What about this? def serialized(lock): def _serialized(func): def __serialized(*args, **kwds): with lock: return func(*args, **kwds) __serialized.__doc__ = func.__doc__ return __serialized return _serialized -- ___ Python tracker <http://bugs.python.org/issue15634> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16798] DTD not checked
New submission from Javier Domingo: Hi, I am trying to find any tip on how to use minidom or etree xml implementations to check the xml syntax. I just found that the only way to check xml syntax throught dtds is using lxml. Would it be possible to implement this in the minidom or ElementTree default lib? I have seen bug http://bugs.python.org/issue2124 that speaks about the dtds fetch, but didn't see any place where it speaks about them being checked. -- components: XML messages: 178353 nosy: txomon priority: normal severity: normal status: open title: DTD not checked type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue16798> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16798] DTD not checked
Javier Domingo added the comment: I am currently using a subprocess with a call to xmllint to make it create a temporal file that gets created on execution for xmllint use. I have seen about lxml, but I wondered if there is any place in the standard python to put xml validation -- ___ Python tracker <http://bugs.python.org/issue16798> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16890] minidom error
New submission from Javier Domingo: Hi I found something like a bug, I can't get this working: import xml.dom.minidom as minidom document=""" """ dom = minidom.parseString(document) dom.childNodes dom.childNodes[0].childNodes dom.childNodes[0].childNodes[1].childNodes def delete_recursive(parent): for child in parent.childNodes: if child.hasChildNodes(): delete_recursive(child) else: parent.removeChild(child) delete_recursive(dom) dom.childNodes dom.childNodes[0].childNodes dom.childNodes[0].childNodes[0].childNodes Executes as: >>> import xml.dom.minidom as minidom >>> document=""" ... ... ... ... ... """ >>> dom = minidom.parseString(document) >>> >>> dom.childNodes [] >>> dom.childNodes[0].childNodes [, , ] >>> dom.childNodes[0].childNodes[1].childNodes [, , , , ] >>> >>> def delete_recursive(parent): ... for child in parent.childNodes: ... if child.hasChildNodes(): ... delete_recursive(child) ... else: ... parent.removeChild(child) ... >>> delete_recursive(dom) >>> >>> dom.childNodes [] >>> dom.childNodes[0].childNodes [] >>> dom.childNodes[0].childNodes[0].childNodes [, , , , ] The problem here is this last line, those text nodes shouldn't be here! I have traced the problem, and seem that the for loop is not correctly executed -- components: XML messages: 179309 nosy: txomon priority: normal severity: normal status: open title: minidom error versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue16890> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16890] minidom error
Javier Domingo added the comment: I know that is the problem, but that shouldn't happen! if you remove a item from a list, that doesn't happen. That is why I tagged the error as minidom's El 08/01/2013 04:24, "Ezio Melotti" escribió: > > Ezio Melotti added the comment: > > The problem is that you are mutating parent.childNodes while you are > iterating on it. Iterating over a copy seems to solve the problem. > > -- > nosy: +ezio.melotti > resolution: -> invalid > stage: -> committed/rejected > status: open -> closed > type: -> behavior > > ___ > Python tracker > <http://bugs.python.org/issue16890> > ___ > -- ___ Python tracker <http://bugs.python.org/issue16890> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16890] minidom error
Javier Domingo added the comment: Ok, sorry then. Javier Domingo 2013/1/8 Ezio Melotti > > Ezio Melotti added the comment: > > It happens with lists too: > >>> l = list(range(10)) > >>> for x in l: > ... l.remove(x) > ... > >>> l > [1, 3, 5, 7, 9] > > -- > > ___ > Python tracker > <http://bugs.python.org/issue16890> > ___ > -- ___ Python tracker <http://bugs.python.org/issue16890> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Juan Javier added the comment: Hi Brian, No, no progress on this. I think this is not an interesting feature after all. You can close this. Juan Javier -- ___ Python tracker <http://bugs.python.org/issue13785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15634] Add serialized decorator to the threading module
Juan Javier added the comment: It looks like this is not very interesting after all. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue15634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Changes by Juan Javier : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue13785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15634] Add serialized decorator to the threading module
Juan Javier added the comment: David, I think this doesn't deserve to be part of the library since it is trivial to write and it is just a particular use case. Adding it as an example in the threading module's documentation might be a good idea, what do you think? -- ___ Python tracker <http://bugs.python.org/issue15634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6751] Default return value in ConfigParser
New submission from Juan Javier : I think it is useful, at least for me, to add an argument, default, to [Safe,Raw]ConfigParser.get that, if present, will be returned if the methid fails to return the value. That is, instead of rasing an exception, return default, if present. It could be done overriding the get method in SafeConfigParser, something like this: class SafeConfigParser(ConfigParser): def get(self, section, option, raw=False, vars=None, **kwds): try: return super().get(section, option, raw, vars) except Exception as exc: if "default" in kwds: return kwds["default"] raise exc -- components: Library (Lib) messages: 91808 nosy: jjdominguezm severity: normal status: open title: Default return value in ConfigParser type: feature request versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue6751> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
Javier Collado added the comment: Working on it. -- ___ Python tracker <http://bugs.python.org/issue9026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
Javier Collado added the comment: Finally I had to use an OrderedDict as suggested by R. David Murray because it wasn't safe to rely on _choices_actions in HelpFormatter class (i.e. previous patch wasn't valid): - _choices_actions attribute is only present in _SubParsersAction class - Even if action object is an instance of _SubParsersAction, _choices_actions only contains data for for subparsers that contain a help description. Regarding the test cases: - TestHelpSubparsersOrdering and TestHelpSubparsersWithHelpOrdering have been added - TestHelpFormattingMetaClass has been modified: - New subparsers_signatures tester attribute added to test subparsers help. - If a 'signatures attribute' isn't present in tester object, then isn't consumed - assertMultilineEqual used instead of assertEqual to make it easier to debug test case failures. -- Added file: http://bugs.python.org/file17730/trunk.diff ___ Python tracker <http://bugs.python.org/issue9026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
Changes by Javier Collado : Removed file: http://bugs.python.org/file17705/ordered_subcommands.diff ___ Python tracker <http://bugs.python.org/issue9026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
Javier Collado added the comment: Despite trunk.diff can be successfully applied to py3k branch, please find attached the patch generated from py3k branch. -- Added file: http://bugs.python.org/file17731/py3k.diff ___ Python tracker <http://bugs.python.org/issue9026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
Javier Collado added the comment: Just for the record, please find attached an uglier patch for python < 2.7 that doesn't have the same problems as the first one I uploaded and passes all the test cases (tested with python 2.6). -- Added file: http://bugs.python.org/file17733/pre27.diff ___ Python tracker <http://bugs.python.org/issue9026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6751] Default return value in ConfigParser
Juan Javier added the comment: I've applied the enhancement to the three parsers, actually I've made the change to RawconfigParser with a small change to ConfigParser. I've also created some unit tests. -- keywords: +patch Added file: http://bugs.python.org/file18122/configparser.py.diff ___ Python tracker <http://bugs.python.org/issue6751> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6751] Default return value in ConfigParser
Changes by Juan Javier : Added file: http://bugs.python.org/file18123/test_cfgparser.py.diff ___ Python tracker <http://bugs.python.org/issue6751> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] argparse subcommands not printed in the same order they were added
Javier Collado added the comment: The hasattr expressions were added to TestHelpFormattingMetaclass because: - A new attribute (subparsers_signature) was added in test classes that wasn't used in the past. - The new test classes didn't make use of some of the already in place attributes (argument_signatures, argument_signatures) - The old test classes didn't make use of the new attribute (subparsers_signature). - TestHelpFormattingMetaclass assumed that those attributes were present in test classes (otherwise an exception was raised). Hence, in order not to change/break a lot of test cases, I decided to add the hasattr expressions. -- ___ Python tracker <http://bugs.python.org/issue9026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6751] Default return value in ConfigParser
Juan Javier added the comment: I would like the method to have the exact same behavior as before if the "default" argument is not present, and return the given default value when "deafult" argument is present. If you simply add a "default" keyword, it will always be present and you wouldn't know if the user wants the exception thrown or the default value returned. Do you know how to program this using a "default" keyword argument? -- ___ Python tracker <http://bugs.python.org/issue6751> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26467] Add async magic method support to unittest.mock.Mock
Javier Domingo added the comment: I found this while trying to test an async context manager. This is a critical feature to enable migrations to async code, as the impossibility to test something properly is not acceptable in many environments. Implementing it in a way that __call__ returns an object capable of being coroutine or normal function would avoid having to implement Async specific Mocks, wouldn't it? I am not too confident, but would it be doable to have an implementation that depends on whether _is_coroutine is accessed or not? I don't like it, but I really don't like the fact that we need to patch different all the methods depending on whether they are coroutine or not. Obviously, having the __acall__ method would really help solving this issue. -- nosy: +txomon ___ Python tracker <http://bugs.python.org/issue26467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29558] Provide run_until_complete inside loop
New submission from Javier Domingo: The current architecture of asyncio makes it really hard to combine both async and sync code. When porting a Thread based application to asyncio, the first step is usually to start merging threads to the main loop, by using `run_coroutine_threadsafe`. This works well and allows to use a single ioloop from different threads. There is another step, that usually involves the patching of libraries to work in an async way. One will typically patch the IO calls to be asyncio, and using `run_until_complete` proves useful in these situations. However, at the moment it's not possible to `run_until_complete` from an ioloop. The possibility to be able to patch sync libraries to run in asyncio is something that would help a lot the migration. This functionality would basically provide a way to continue running the ioloop until the future is resolved. Sync code -> async code -> Sync code -> Async code If you know how to have this without spawning an executor, that would be good too, in such case I would rather ask for documentation on how to do it =) -- components: asyncio messages: 287784 nosy: gvanrossum, txomon, yselivanov priority: normal severity: normal status: open title: Provide run_until_complete inside loop type: enhancement versions: Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue29558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29558] Provide run_until_complete inside loop
Javier Domingo added the comment: Yes, indeed it is. Would it be possible to reconsider this functionality? It plays a key role when trying to rewrite full applications to async. Rewriting the full stack of libraries at once is impossible, but the patching can easily be done in many cases. -- ___ Python tracker <http://bugs.python.org/issue29558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28525] Incorrect documented parameter for gc.collect
Changes by Javier Rey : -- assignee: docs@python components: Documentation files: gc_collect_doc_fix.patch keywords: patch nosy: docs@python, vierja priority: normal severity: normal status: open title: Incorrect documented parameter for gc.collect versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45209/gc_collect_doc_fix.patch ___ Python tracker <http://bugs.python.org/issue28525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21622] ctypes.util incorrectly fails for libraries without DT_SONAME
Change by Javier Castillo II : -- pull_requests: +16469 pull_request: https://github.com/python/cpython/pull/16940 ___ Python tracker <https://bugs.python.org/issue21622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21622] ctypes.util incorrectly fails for libraries without DT_SONAME
Javier Castillo II added the comment: The PR 10460 ( for 3.8 ) patches the search attempts to leverage LD_LIBRARY_PATH for the Linux case and catches the case after SONAME, gcc and ldconfig behaviors fail. While this may not be set in all environments ( like the musl based Alpine docker image ) setting the environment variable is within the user's control and when properly set does return found libraries. PR 10461 and PR 10462 are closed for now, as backports to 2.7 and 3.7 need to have the 3.8 accepted first before being reviewed. -- nosy: +jcastillo2nd ___ Python tracker <https://bugs.python.org/issue21622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21622] ctypes.util incorrectly fails for libraries without DT_SONAME
Change by Javier Castillo II : -- pull_requests: +9730 ___ Python tracker <https://bugs.python.org/issue21622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21622] ctypes.util incorrectly fails for libraries without DT_SONAME
Change by Javier Castillo II : -- pull_requests: +9734 ___ Python tracker <https://bugs.python.org/issue21622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21622] ctypes.util incorrectly fails for libraries without DT_SONAME
Change by Javier Castillo II : -- pull_requests: +9735 ___ Python tracker <https://bugs.python.org/issue21622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21622] ctypes.util incorrectly fails for libraries without DT_SONAME
Change by Javier Castillo II : -- pull_requests: +9736 ___ Python tracker <https://bugs.python.org/issue21622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16473] Minor difference in decoding quoted-printable text
New submission from Alejandro Javier Peralta Frías:
New to python-dev; I grab a beginner tasks "increase test coverage" and I
decided to add coverage to this bit of code in the quopri module:
# quopri.py
L138while n > 0 and line[n-1:n] in b" \t\r":
L139n = n-1
As far as I understand to get into that while-loop the line to decode should
end in " \t\r\n".
So the I added the following test:
def test_decodestring_badly_enconded(self):
e = b"hello \t\r\n"
p = b"hello\n"
s = self.module.decodestring(e)
self.assertEqual(s, p)
but that only passes when the module doesn't use binascii. In fact I change
test_quopri to use support.import_fresh_module to disable binascii and removed
a decorator that was used.
The decode text when binascci is used is:
>>> quopri.decodestring("hello \t\r\n")
'hello \t\r\n'
which differs from
>>> quopri.a2b_qp = None
>>> quopri.b2a_qp = None
>>> quopri.decodestring("hello \t\r\n")
'hello\n
And what's the deal with:
>>> import quopri
>>> quopri.encodestring("hello \t\r")
'hello \t\r'
>>> "hello \t\r".encode("quopri")
'hello=20=09\r'
--
components: Tests
files: test_quopri.diff
keywords: patch
messages: 175593
nosy: aleperalta
priority: normal
severity: normal
status: open
title: Minor difference in decoding quoted-printable text
versions: Python 3.3
Added file: http://bugs.python.org/file27985/test_quopri.diff
___
Python tracker
<http://bugs.python.org/issue16473>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16473] Minor difference in decoding quoted-printable text
Changes by Alejandro Javier Peralta Frías : -- nosy: +brett.cannon ___ Python tracker <http://bugs.python.org/issue16473> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16473] Minor difference in decoding quoted-printable text
Alejandro Javier Peralta Frías added the comment: I think I can answer your last question. There are two quopri algorithms, > one where spaces are allowed (message body) and one where they aren't > (email headers). > > OK, thank you. Good to know. -- ___ Python tracker <http://bugs.python.org/issue16473> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
