[issue43796] "install" package on PyPI
New submission from Jared Ondricek : I recently accidentally typed "pip install pip install " and it installed a package called "install" that has 1 star on GitHub. It is also in use by 2.3k repositories according to the GitHub dependency graph view. I don't think it's malicious, but it does seem a bit sketchy. I just know this sort of thing has been in the news lately, and maybe this is that sort of thing that ought to be looked at by someone smarter than me about security stuff. The way Perl deals with this specific issue is by using a specific dummy module so no one can do this on accident. Is this worth the time to discuss? Or am I just being paranoid about a third party library called install? PyPI entry: https://pypi.org/project/install/ GitHub page: https://github.com/eugenekolo/pip-install GitHub projects that depend on it: https://github.com/eugenekolo/pip-install/network/dependents?package_id=UGFja2FnZS0xMjU0NTI3MDI5 Perl dummy install module: https://metacpan.org/pod/install -- messages: 390647 nosy: flamableconcrete priority: normal severity: normal status: open title: "install" package on PyPI type: security ___ Python tracker <https://bugs.python.org/issue43796> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43620] os.path.join does not use os.sep as documentation claims
Jared Sutton added the comment: Thank you for understanding my position, Fred. I submitted a draft PR (25025) for this bug. -- ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43620] os.path.join does not use os.sep as documentation claims
Change by Jared Sutton : -- keywords: +patch pull_requests: +23775 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25025 ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43620] os.path.join does not use os.sep as documentation claims
Jared Sutton added the comment: > Perhaps Jared was expecting that modifying os.sep would affect the functions > in os.path? This is precisely what I thought, because the documentation makes it sound like that variable named os.sep is read and used as the path delimiter when constructing something with join(). In fact, that variable isn't read *at all* because the path separator is hard-coded in both posixpath.py and ntpath.py. Since os.sep isn't used, I see no reason why it should be referenced in the documentation at all. I'm not trying to be pedantic here (though we nerds are famous for that :) ), but what I see here is a disagreement between what is documented and what actually exists in the implementation. Yes the *value* of os.sep happens to be the same as the one hard-coded into either ntpath or posixpath, but since that variable is not referenced in the implementation, its presence in the doc only serves to confuse people who take the documentation at face value and then get an unexpected result. -- ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43620] os.path.join does not use os.sep as documentation claims
Jared Sutton added the comment: I can understand your suggestion to just utilize the posixpath library on Windows if needed. That's a reasonable work-around. But certainly you can see this is a doc bug, since the doc clearly states that os.sep is utilized to join the elements of the path, when it clearly isn't; right? -- components: -Library (Lib) ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43620] os.path.join does not use os.sep as documentation claims
New submission from Jared Sutton : The behavior of os.path.join() does not match the documentation, in regards to the use of os.sep. From the docs: """ The return value is the concatenation of path and any members of *paths with exactly one directory separator (os.sep) following each non-empty part except the last, meaning that the result will only end in a separator if the last part is empty. """ The documentation clearly states that the function uses the value of os.sep (which differs based on platform). However, if you review the 2 implementations (ntpath.py and posixpath.py), the separator character used is clearly hard-coded and doesn't reference os.sep at all. One could say that this is either a doc bug or an implementation bug, depending on what the intended behavior is. I submit that this is an implementation bug, as one might want to use os.path.join() to construct a path to be used on a platform other than the one currently running the application. For example, a person might be running Python on Windows, but calling a web API and constructing a path for use on a remote posix system. -- assignee: docs@python components: Documentation, Library (Lib) messages: 389489 nosy: docs@python, jpsutton priority: normal severity: normal status: open title: os.path.join does not use os.sep as documentation claims type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34257] SSL should accept cert content, instead of just cert file path
Jared added the comment: Also [PEP 543](https://www.python.org/dev/peps/pep-0543/) is related to this. In addition, I think [PyOpenSSL](https://pyopenssl.org/en/stable/index.html) provides support for what you want. -- nosy: +j-rewerts ___ Python tracker <https://bugs.python.org/issue34257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34258] Python shell keeps restarting
Jared added the comment: First off, no judgment! :) I just want to get some more details from you. 1) How are you running your program? 2) How far into your program do you get? 3) What are you passing in as values for your Input() calls? -- nosy: +j-rewerts ___ Python tracker <https://bugs.python.org/issue34258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34266] Bad behavior with "restart \" or "restart "" in pdb
Jared added the comment: Good! Is it possible to start a python program with either \ or " as arguments normally (without using character escaping)? -- ___ Python tracker <https://bugs.python.org/issue34266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34266] Bad behavior with "restart \" or "restart "" in pdb
Jared added the comment: Would it be possible to escape both of those? For the first one, restart "\\" and for the second one, restart "\"" -- ___ Python tracker <https://bugs.python.org/issue34266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34266] Bad behavior with "restart \" in pdb
Jared added the comment: I wouldn't mind taking a look at this. Feel free to assign it to me! -- nosy: +j-rewerts ___ Python tracker <https://bugs.python.org/issue34266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32752] no information about accessing typing.Generic type arguments
Jared Deckard added the comment: typing_inspect is now filled with python version checks for 3.7. The implementation got significantly more complex when differentiating generics at runtime. 3.6 was undocumented, but the OO API was intuitive: >>> T = typing.Union[int, float] >>> assert T.__class__ == typing.Union >>> assert T.__args__ == (int, float) 3.7 is less convenient and less consistent: >>> T = typing.Union[int, float] >>> assert T.__class__ == typing._GenericAlias >>> assert T.__origin__ == typing.Union >>> L = typing.List[int] >>> assert L.__class__ == typing._GenericAlias >>> assert L.__origin__ == list -- nosy: +Jared Deckard ___ Python tracker <https://bugs.python.org/issue32752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser
Jared Deckard added the comment: That is correct. (Thank you for whipping up a repro script from my description). I appreciate the work around, but it is nearly as verbose as manually duplicating the parameters on the child and I would have to type up a large comment block to educate future developers on the hack. Is there some documentation I am missing or is the "resolve" conflict handler broken? > The parents= argument takes a list of ArgumentParser objects, collects all > the positional and optional actions from them, and adds these actions to the > ArgumentParser object being constructed. https://docs.python.org/3.6/library/argparse.html#parents It would be nice if the "error" conflict handler ignored conflicts when the actions are identical. It should be expected that the "resolve" conflict handler would not modify the parents. It is exhibiting undocumented and undesirable side effect, which indicates to me that it is a bug not a missing feature. As for the patch, I'm not sure why you would ever want "action_copy" to be False. It seems like creating copies to insulate the originals ignores the underlying issue that these parents are being mutated when the operation implies a union of properties with no side effects. I don't think the fix for this should be behind an optional flag, I think the fix is to update "resolve" to take into consideration multiple parents like the custom conflict handler in your sample. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser
Jared Deckard added the comment: Adding back components and version data I unintentionally removed in http://bugs.python.org/msg262314 -- components: +Documentation, Tests versions: +Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser
Jared Deckard added the comment: This behavior is preventing me from using more than one parent parser. My use case is a convenience subcommand that performs two existing subcommands, therefore logically its subparser is required to support the arguments of both subparsers. The only conflict is the "help" argument, which is annoying, but setting the conflict handler to "resolve" on the child subparser should just ignore the first parent's "help" argument in favor of the second parent. Instead the "resolve" conflict handler breaks the first parent and causes it to output the help info no matter what arguments are given to it. I am forced to only include one parent and manually duplicate the arguments for any additional parents. -- components: -Documentation, Tests nosy: +deckar01 versions: +Python 2.7 -Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25174] Backspace Escape Character at End of String
New submission from Jared Bevis: I'm a new python learner but I noticed inconsistent behavior of the backspace character when used in strings. I'm running 2.7.10. Whenever the backspace character '\b' is at the very end of a string, nothing happens, but if it is in the middle of string it behaves as expected. For example: print "12345" + '\b' returns: >>>12345 But: print "12345" + '\b' + '6' returns: >>> 12346 -- components: Regular Expressions messages: 251049 nosy: Jared Bevis, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Backspace Escape Character at End of String type: behavior versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25174> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16990] re: match of nongreedy regex not grouping right
New submission from Jared Grubb:
re.match matches, but the capture groups are empty. That's not possible.
Python 2.7.2 (default, Oct 11 2012, 20:14:37)
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type help, copyright, credits or license for more information.
import re
re.match('.*', 'stuff').group() # greedy matches and captures; cool.
'stuff'
re.match('.*?', 'stuff').group() # nongreedy matches (cool) but doesnt
capture (huh?)
''
--
components: Library (Lib)
messages: 180162
nosy: jaredgrubb
priority: normal
severity: normal
status: open
title: re: match of nongreedy regex not grouping right
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16990
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16990] re: match of nongreedy regex not grouping right
Jared Grubb added the comment:
Yes:
re.match('.*', '')
_sre.SRE_Match object at 0x107c6d308
re.match('.*?', '')
_sre.SRE_Match object at 0x107c6d370
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16990
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16990] re: match of nongreedy regex not grouping right
Jared Grubb added the comment: You're right. My mistake. I thought match meant the full string must match, but in Python it means the beginning must match. Sorry for the noise. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16990 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9670] Exceed Recursion Limit in Thread
New submission from Jared Lang jsl...@mail.ucf.edu: Recursion within a thread on OSX can result in a crash by exceeding the systems recursion limit. Recursion behaves as expected if not in thread, meaning it throws a RunTimeError with the message maximum recursion depth exceeded. The crash is able to be avoided if the recursion limit is set to a lower number, ie. 800, via sys.setrecursionlimit. Example program which crashes on OSX: def f(): ... return f() ... import threading thread = threading.Thread(target=f) thread.start() Bus error Alternatively, the following works as expected: import sys def f(): ... return f() ... import threading thread = threading.Thread(target=f) sys.setrecursionlimit(800) thread.start() Exception in thread Thread-1: Traceback (most recent call last): File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py, line 532, in __bootstrap_inner self.run() File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py, line 484, in run self.__target(*self.__args, **self.__kwargs) File stdin, line 2, in f File stdin, line 2, in f File stdin, line 2, in f File stdin, line 2, in f File stdin, line 2, in f File stdin, line 2, in f ... RuntimeError: maximum recursion depth exceeded -- assignee: ronaldoussoren components: Macintosh messages: 114787 nosy: jaredlang, ronaldoussoren priority: normal severity: normal status: open title: Exceed Recursion Limit in Thread type: crash versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9670 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7432] Py3k doc: from __future__ import division not necessary
New submission from Jared Grubb pyt...@jaredgrubb.com: In the Python 3.1 docs for the 'dis' module, the following appears: ( http://docs.python.org/3.1/library/dis.html ) BINARY_TRUE_DIVIDE()¶ Implements TOS = TOS1 / TOS when from __future__ import division is in effect. There is always true in 3k, correct? The when clause should be removed. -- assignee: georg.brandl components: Documentation messages: 95950 nosy: georg.brandl, jaredgrubb severity: normal status: open title: Py3k doc: from __future__ import division not necessary versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7432 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7432] Py3k doc: from __future__ import division not necessary
Jared Grubb pyt...@jaredgrubb.com added the comment: Ditto on a few dozen lines later: INPLACE_TRUE_DIVIDE()¶ Implements in-place TOS = TOS1 / TOS when from __future__ import division is in effect. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7432 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7343] What's new in 3.0 says % operator will be deprecated in 3.1
New submission from Jared Grubb pyt...@jaredgrubb.com: The existing text: http://www.python.org/doc/3.0/whatsnew/3.0.html A new system for built-in string formatting operations replaces the % string formatting operator. (However, the % operator is still supported; it will be deprecated in Python 3.1 and removed from the language at some later time.) Read PEP 3101 for the full scoop. Python 3.1 did not deprecate the % operator, right? Is it appropriate to edit the 3.0 docs to reflect that? -- assignee: georg.brandl components: Documentation messages: 95411 nosy: georg.brandl, jaredgrubb severity: normal status: open title: What's new in 3.0 says % operator will be deprecated in 3.1 versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Jared Grubb pyt...@jaredgrubb.com added the comment: I think ANY attempt to rely on eval(repr(x))==x is asking for trouble, and it should probably be removed from the docs. Example: The following C code can vary *even* on a IEEE 754 platform, even in two places in the same source file (so same compile options), even in the same 5 lines of code recompiled after changing code that does even not touch/read 'x' or 'y': double x, y; x = 3.0/7.0; y = x; /* ... code that doesnt touch/read x or y ... */ printf( x==y: %s, (x==y) ? true : false); So, how can we hope that eval(repr(x))==x is EVER stable? Equality and floating point should raise the hairs on the back of everyone's neck... (Code above based on http://docs.sun.com/source/806-3568/ncg_goldberg.html in section Current IEEE 754 Implementations, along with a great explanation on why this is true. The code example is a little different, but the same concept applies.) -- nosy: +jaredgrubb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1580 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Jared Grubb pyt...@jaredgrubb.com added the comment: The process that you describe in msg85741 is a way of ensuring memcmp(x, y, sizeof(x))==0, and it's portable and safe and is the Right Thing that we all want and expect. But that's not x==y, as that Sun paper explains. It's close, but not technically accurate, as the implication arrow only goes one way (just as x=1/y implies xy=1 in algebra, but not the other way around) I'd be interested to see if you could say that the Python object model/bytecode interpretation enforces a certain quauntum of operations that actually does imply eval(repr(x))==x; but I suspect it's unprovable, and it's fragile as Python grows to have more support in CLI/LLVM/JVM backends. My pedantic mind would strip any and all references to floating-point equality out of the docs, as it's dangerous and insidiously misleading, even in obvious cases. But, I'll stop now :) (FYI: I've enjoyed the ~100 messages here.. Great stuff!) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1580 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5349] abstractmethod vs C++ pure virtual
New submission from Jared Grubb pyt...@jaredgrubb.com:
On page library/abc.html documenting abc.abstractmethod, the following
text about C++ is placed in a note:
Note: Unlike C++’s pure virtual functions, or Java abstract methods,
these abstract methods may have an implementation. This implementation
can be called via the super() mechanism from the class that overrides
it. This could be useful as an end-point for a super-call in a framework
that uses cooperative multiple-inheritance.
This is not an accurate description of C++'s pure virtual functions.
Pure virtual functions CAN have an implementation, which can be called
from derived classes; this makes them behave just like Python's
abstractmethod.
Example:
struct Abstract {
virtual void foo() = 0;
};
void Abstract::foo() {
std::cout pure virtual function called;
}
struct Derived : public Abstract {
virtual void foo() {
Abstract::foo(); // call the abstract impl
}
};
--
assignee: georg.brandl
components: Documentation
messages: 82618
nosy: georg.brandl, jaredgrubb
severity: normal
status: open
title: abstractmethod vs C++ pure virtual
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5349
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
jared jennings [EMAIL PROTECTED] added the comment: According to §7.1.3 of the C99 standard, the name __int128_t is reserved for implementation-specific use because it starts with an underscore. So if gcc defines this type and icc does not, that is not a bug in icc; and if Python uses this type, it will only certainly build using gcc. I doubt such a dependency was intended, because it is not documented, and no error was thrown when the autoconf script detected that a compiler other than GCC was being used. C99 standard: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf Exact-width integer types (e.g. int64_t) are documented in §7.18.1.1 of the above. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
New submission from jared jennings [EMAIL PROTECTED]: If the Intel 9.1 compilers are used to compile Python 2.6, the following compiler error results: /mnt/gpfs/usrpeople/jenninjl/Python-2.6-intel/Modules/_ctypes/libffi/src/x86/ffi64.c(43): error: identifier __int128_t is undefined __int128_t sse[MAX_SSE_REGS]; ^ Forum thread regarding lack of support for __int128_t in icc: http://software.intel.com/en-us/forums/intel-c-compiler/topic/56652/ Intel C++ Compiler 10.1 for Linux, Intrinsic Reference: http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/347603.pdf The Intrinsic Reference details (pp. 2-4) the __m128 type supported by the Intel compiler, and restrictions on its use. (Note that the compiler used was 9.1 but the documentation is from 10.1.) -- assignee: theller components: ctypes messages: 74813 nosy: jared.jennings, theller severity: normal status: open title: Intel icc 9.1 does not support __int128_t used by ctypes type: compile error versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2182] tokenize: does not allow CR for a newline
Jared Grubb [EMAIL PROTECTED] added the comment:
Yes, but exec(string) also gives a syntax error for \r\n:
exec('x=1\r\nprint x')
The only explanation I could find for ONLY permitting \n as newlines in
exec(string) comes from PEP278: There is no support for universal
newlines in strings passed to eval() or exec. It is envisioned that such
strings always have the standard \n line feed, if the strings come from
a file that file can be read with universal newlines. (This is why my
original example had to be exec(file) and not just a simple exec(string))
Of the 3 newline types, exec(*) allows 1 or all 3 as the case may be,
and tokenize allows exactly 2 of them. I honestly am not sure what the
right way is (or should be), but either way, the tokenize module is
not consistent with exec.
(By the way, if you're curious why I filed this issue and Issue#2180,
I'm working on the PyPy project to help improve its current Python
lexer/parser. In order to ensure that it is correct and robust, I was
experimenting with corner cases in Python syntax and I found these cases
where tokenize disagrees with exec.)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2182
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2182] tokenize: does not allow CR for a newline
Jared Grubb [EMAIL PROTECTED] added the comment: I actually hadnt thought of that. PyPy should actually use universal newlines to its advantage; after all, it IS written in Python... Thanks for the suggestion! In any case, I wanted to get this bug about the standard library in your record, in case you wanted to handle it. It is fairly innocuous, so I'll let it go. Take care. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2182] tokenize: does not allow CR for a newline
Jared Grubb [EMAIL PROTECTED] added the comment: This is not a report on a bug in exec(), but rather a bug in the tokenize module -- the behavior between the CPython tokenizer and the tokenize module is not consistent. If you look in the tokenize.py source, it contains code to recognize both \n and \r\n as newlines, but it ignores the possibility that \r could be the line ending character (as the Python reference says). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2273] test_decimal: possible thread lockup in test case
New submission from Jared Grubb [EMAIL PROTECTED]: In Lib\test\test_decimal.py, attached is a bugfix for two bugs: 1) If the thfunc2 actually fails, then its thread will throw an exception and never set the Events that thfunc1 is waiting for; thus, thfunc1 never returns, causing the whole unittest to hang. 2) DecimalUseOfContextTest.test_threading should wait on both finish1 and finish2 (instead of waiting on finish1 twice). -- components: Library (Lib) files: test_decimal.patch keywords: patch messages: 63463 nosy: jaredgrubb severity: normal status: open title: test_decimal: possible thread lockup in test case type: crash versions: Python 2.5 Added file: http://bugs.python.org/file9656/test_decimal.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2273 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2273] test_decimal: possible thread lockup in test case
Jared Grubb [EMAIL PROTECTED] added the comment: I ran into this bug because I created a context manager in one of my own projects, and the regression tests in test_decimal looked like a good start for my own regression tests... when some recent changes broke MY code, I found the test bug too and realized that the test_decimal file had the same problem. So, I figured I'd share the wealth :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2273 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2180] tokenize: mishandles line joining
Changes by Jared Grubb: -- components: Extension Modules nosy: jaredgrubb severity: minor status: open title: tokenize: mishandles line joining type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2180 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2180] tokenize: mishandles line joining
New submission from Jared Grubb: tokenize does not handle line joining properly, as the following string fails the CPython tokenizer but passes the tokenize module. Example 1: s = if 1:\n \\\n #hey\n print 1 exec s Traceback (most recent call last): File stdin, line 1, in module File string, line 3 #hey ^ SyntaxError: invalid syntax tokenize.tokenize(StringIO(s).readline) 1,0-1,2:NAME'if' 1,3-1,4:NUMBER '1' 1,4-1,5:OP ':' 1,5-1,6:NEWLINE '\n' 2,0-2,2:INDENT ' ' 3,2-3,6:COMMENT '#hey' 3,6-3,7:NEWLINE '\n' 4,2-4,7:NAME'print' 4,8-4,9:NUMBER '1' 5,0-5,0:DEDENT '' 5,0-5,0:ENDMARKER '' __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2180 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2182] tokenize: does not allow CR for a newline
New submission from Jared Grubb:
tokenize recognizes '\n' and '\r\n' as newlines, but does not tolerate '\r':
s = print 1\nprint 2\r\nprint 3\r
open('temp.py','w').write(s)
exec(open('temp.py','r'))
1
2
3
tokenize.tokenize(open('temp.py','r').readline)
1,0-1,5:NAME'print'
1,6-1,7:NUMBER '1'
1,7-1,8:NEWLINE '\n'
2,0-2,5:NAME'print'
2,6-2,7:NUMBER '2'
2,7-2,9:NEWLINE '\r\n'
3,0-3,5:NAME'print'
3,6-3,7:NUMBER '3'
3,7-3,8:ERRORTOKEN '\r'
4,0-4,0:ENDMARKER ''
--
components: Extension Modules
messages: 62959
nosy: jaredgrubb
severity: minor
status: open
title: tokenize: does not allow CR for a newline
type: behavior
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2182
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2180] tokenize: mishandles line joining
Jared Grubb added the comment:
CPython allows \ at EOF, but tokenize does not.
s = 'print 1\\\n'
exec s
1
tokenize.tokenize(StringIO(s).readline)
1,0-1,5:NAME'print'
1,6-1,7:NUMBER '1'
Traceback (most recent call last):
File stdin, line 1, in module
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/tokenize.py,
line 153, in tokenize
tokenize_loop(readline, tokeneater)
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/tokenize.py,
line 159, in tokenize_loop
for token_info in generate_tokens(readline):
File
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/tokenize.py,
line 283, in generate_tokens
raise TokenError, (EOF in multi-line statement, (lnum, 0))
tokenize.TokenError: ('EOF in multi-line statement', (2, 0))
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2180
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
