[issue3568] list enumeration corrupt when remove()
New submission from Jacek <[EMAIL PROTECTED]>:
Hi
I wrote my first program in python, and I found bug in it.
I explain it in example (I do it under Windows XP):
1. At the begining create some directories:
>mkdir .\test\
>mkdir .\test\.svn
>mkdir .\test\cvs
>mkdir .\test\pdk
2. Next create file ".\bug.py" with content:
import re
import os
print 'example1:'
lpatternDirSkip = re.compile(r'(^cvs$)|(^[.].*)', re.IGNORECASE)
for lroot, ldirs, lfiles in os.walk(r'.\\test\\'):
ldirIndex = 0
for ldirName in ldirs:
if lpatternDirSkip.search(ldirName):
ldirs.remove(ldirName)
print ldirs
print 'example2:'
lpatternDirSkip = re.compile(r'(^cvs$)|(^[.].*)', re.IGNORECASE)
for lroot, ldirs, lfiles in os.walk('.\\test\\'):
ldirIndex = 0
while ldirIndex < len(ldirs):
if lpatternDirSkip.search(ldirs[ldirIndex]):
ldirs.remove(ldirs[ldirIndex])
ldirIndex -= 1
ldirIndex += 1
print ldirs
3. Next run cmd.exe (in the same directory) and type "bug.py". Result is:
example1:
['cvs', 'pdk']
[]
[]
example2:
['pdk']
[]
5. Comment:
In this example I want to remove from list of directories (ldirs) every
hiden directories (like ".svn") and directory "CVS".
Example1 is the comfortable way, but it products wrong result (the "cvs"
directory is not remove). This is only happen when I remove some
directories from the list. I don't care that there was deleted one
element from the list. It should be special case, and enumeration on the
rest elements should be correct.
Example2 works correcty (it's work around of this problem).
Jacek Jaworski
--
components: Build
messages: 71230
nosy: jacek
severity: normal
status: open
title: list enumeration corrupt when remove()
type: behavior
versions: Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3568>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45715] round(2500, -3)
New submission from Jacek : round(2500, -3) returns 2000 instead of 3000. I have checked it on 3.7.4 and 3.6.9. -- components: Library (Lib) messages: 405726 nosy: jacekblaz priority: normal severity: normal status: open title: round(2500, -3) type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue45715> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12551] Provide data for TLS channel binding
New submission from Jacek Konieczny :
Recently IETF encourages using of the SCRAM-SHA-1-PLUS SASL authentication
mechanism (5802) in new protocols. That is a requirement e.g. of the current
XMPP specification (RFC6120). Any compliant implementation needs to support the
'SCRAM-SHA-1-PLUS' mechanism, and that requires obtaining the 'tls-unique'
channel-binding data from a TLS connection used. Python doesn't provide this
information and it seems the only detail stopping anyone from fully
implementing XMPP or SCRAM-SHA-1-PLUS alone in Python.
The 'tls-unique' channel binding is defined as:
> Description: The first TLS Finished message sent (note: the Finished
> struct, not the TLS record layer message containing it) in the most
> recent TLS handshake of the TLS connection being bound to
…and is (they say), available via OpenSSL API. This should be exposed by the
python SSLSocket object too.
The other channel-binding data type, 'tls-server-end-point' can be computed
using current Python API, but it is not enough for most uses ('tls-unique' is
the required channel binding data in most cases) and still not trivial (one
needs to ASN.1-decode the certificate to get the hash function name to compute
proper digest).
--
components: Library (Lib)
messages: 140247
nosy: Jajcus
priority: normal
severity: normal
status: open
title: Provide data for TLS channel binding
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue12551>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12551] Provide data for TLS channel binding
Jacek Konieczny added the comment: > Do you happen to know which API? Not yet. > I see no reference to tls-unique or channel binding, in either the OpenSSL > website or the latest OpenSSL snapshot. Yes, I know it is not directly documented. > It would be nice if there was some ready-to-use code (I'm not a crypto > expert). _Maybe_ I will try to hack the python SSL code to make this work within my project. I will attach a patch here if it happens and gives any reusable results. As for now I cannot help any more, I am just reporting what is missing. -- ___ Python tracker <http://bugs.python.org/issue12551> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12551] Provide data for TLS channel binding
Jacek Konieczny added the comment: I skim-read the TLS specification, looked at the OpenSSL API and it seems it should be easy to implement. I am getting to work right now… -- ___ Python tracker <http://bugs.python.org/issue12551> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12551] Provide data for TLS channel binding
Jacek Konieczny added the comment: Here is a patch, ready for review. Seems to work, though I still need to check it with some other implementation. I have chosen not to expose another three OpenSSL functions (SSL_get_finished, SSL_get_peer_finished, SSL_session_reused), but provide API just for getting the channel binding. If OpenSSL provides a better API some day (gnutls already has a dedicated function), we can use that. The method added to SSLSocket - get_channel_binding() currently can return only the 'tls-unique' channel binding type, but can be easily extended for other types, which also may be easier to get from the C module. -- keywords: +patch Added file: http://bugs.python.org/file22646/tls_channel_binding.patch ___ Python tracker <http://bugs.python.org/issue12551> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12551] Provide data for TLS channel binding
Jacek Konieczny added the comment: Thanks for the quick review. Most of the problems are my oversights. I am not sure about that: > And I think get_channel_binding() should raise NotImplementedError in that > case. As the method is supposed to be extensible and 'tls-unique' may be just one of possible channel-binding types, then I think the same exception should be raised in case 'tls-unique' is requested and not implemented and when other, currently not implemented, channel binding type is requested. The get_channel_binding() method itself is always implemented, that is why I wonder if 'ValueError' is no better. Or 'NotImplementedError' for both 'tls-unique not implemented' and 'unknown channel binding'. -- ___ Python tracker <http://bugs.python.org/issue12551> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12551] Provide data for TLS channel binding
Jacek Konieczny added the comment: This is patch updated according to your suggestions, including raising NotImplementedError when 'tls-unique' is not available and with the ssl.HAS_TLS_UNIQUE constant added. It also includes an important fix to the data retrieval logic (one condition had to be reverted). Now the code is proven to work, by testing with another implementation (SCRAM-SHA-1-PLUS authentication in Isode M-Link 15.1a0). A alternative patch version will follow. -- Added file: http://bugs.python.org/file22651/tls_channel_binding.patch ___ Python tracker <http://bugs.python.org/issue12551> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12551] Provide data for TLS channel binding
Jacek Konieczny added the comment: This patch is functionally equivalent, but advertises 'tls-unique' support in a bit different way. HAS_TLS_UNIQUE is not exposed in the python 'ssl' module, instead a list 'CHANNEL_BINDING_TYPES' is provided (empty when 'tls-unique' is not supported). get_channel_binding raises ValueError if the argument is not on this list. This way the API can be extended to other channel binding types without adding new constants or functions. Adding a new channel binding type would not need any modifications in the API client code (if it is designed to use arbitrary cb types). -- Added file: http://bugs.python.org/file22652/tls_channel_binding_alt.patch ___ Python tracker <http://bugs.python.org/issue12551> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12793] allow filters in os.walk
New submission from Jacek Pliszka : I suggest a small change in os.walk module. Instead of: def walk(top, topdown=True, onerror=None, followlinks=False): I would like to have: def walk(top, topdown=True, onerror=None, skipnames=lambda x : False, skipdirs=islink): Implementation might be as follows: < if isdir(join(top, name)): --- > fullname=join(top, name) > if skipnames(fullname): > continue > if isdir(fullname): and: < if followlinks or not islink(new_path): < for x in walk(new_path, topdown, onerror, followlinks): --- > if not skipdirs(new_path): > for x in walk(new_path, topdown, onerror, skipnames, skipdirs): This is a small change, breaks a bit 'followlinks' option but gives much more flexibility as skipnames and skidirs can be any functions (including ones using regexp and similar). -- components: Library (Lib) files: os.diff keywords: patch messages: 142523 nosy: Jacek.Pliszka priority: normal severity: normal status: open title: allow filters in os.walk type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file22960/os.diff ___ Python tracker <http://bugs.python.org/issue12793> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12793] allow filters in os.walk
Changes by Jacek Pliszka : -- versions: +Python 2.7 -Python 3.2 ___ Python tracker <http://bugs.python.org/issue12793> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12793] allow filters in os.walk
Jacek Pliszka added the comment:
Looks like the proper way to do it is described in the manual:
http://docs.python.org/dev/library/os.html#os.walk
for root, dirs, files in os.walk('python/Lib/email'):
if 'CVS' in dirs:
dirs.remove('CVS') # don't visit CVS directories
.
I checked that it is covered by unit tests in /test_os.py so it is safe to use
and bug can blo closed as invalid.
--
resolution: -> invalid
___
Python tracker
<http://bugs.python.org/issue12793>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10757] zipfile.write, arcname should be bytestring
New submission from Jacek Jabłoński :
file = 'somefile.dat'
filename = "ółśąśółąś.dat"
zip = zipfile.ZipFile('archive.zip', 'w', zipfile.ZIP_DEFLATED)
zip.write(file, filename)
above produces very nasty filename in zip archive.
*
file = 'somefile.dat'
filename = "ółśąśółąś.dat"
zip = zipfile.ZipFile('archive.zip', 'w', zipfile.ZIP_DEFLATED)
zip.write(file, filename.encode('cp852'))
this produces TypeError: expected an object with the buffer interface
Documentation says that:
There is no official file name encoding for ZIP files. If you have unicode file
names, you must convert them to byte strings in your desired encoding before
passing them to write().
I convert them to byte string but it ends with an error.
If it is documentation bug, what is the proper way to have filenames like
"ółśąśółąś" in zip archive?
--
components: Library (Lib)
messages: 124499
nosy: connexion2000
priority: normal
severity: normal
status: open
title: zipfile.write, arcname should be bytestring
type: compile error
versions: Python 3.1
___
Python tracker
<http://bugs.python.org/issue10757>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26794] curframe can be None in pdb.py
Jacek Pliszka added the comment: Haven't seen it since then. Stopped using 2.7 - using 3.6 in production and 3.7 in development now. I believe it can be closed. -- ___ Python tracker <https://bugs.python.org/issue26794> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15936] Add link from os.urandom to random.SystemRandom
New submission from Jacek Bzdak: It would be great if one sentence was added to os.urandom description: "For easy to use interface to system randomness please see random.SystemRandom class". The reason for this change is that many references quote only os.urandom as a cryptographically strong randomeness source in python, and for some people it might be not obvious that there already exists such easy to use api to use cryptographically strong randomness (that is random.SystemRandom class). It would be good to point such people to right class. Myself for example spent last hour trying to create makeshift Random subclass that uses os.urandom as it's randomness source. -- assignee: docs@python components: Documentation messages: 170423 nosy: Jacek.Bzdak, docs@python priority: normal severity: normal status: open title: Add link from os.urandom to random.SystemRandom type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue15936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19217] Calling assertEquals for moderately long list takes too long
New submission from Jacek Bzdak: Call to assertEquals(list1, list2) does not finish (takes more than couple of minutes), for lists that containt 1 elements if all list elements are different. The same call in python2.6 finishes instanteneously. This occours even if error message is truncated using maxDiff. -- components: Library (Lib) files: unittest_scse.py messages: 199383 nosy: Jacek.Bzdak priority: normal severity: normal status: open title: Calling assertEquals for moderately long list takes too long type: resource usage versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file32033/unittest_scse.py ___ Python tracker <http://bugs.python.org/issue19217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19217] Calling assertEquals for moderately long list takes too long
Jacek Bzdak added the comment: I have attached a simple test case. -- ___ Python tracker <http://bugs.python.org/issue19217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19217] Calling assertEquals for moderately long list takes too long
Jacek Bzdak added the comment: The patch works for me, thanks Ezio! -- ___ Python tracker <http://bugs.python.org/issue19217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20240] Whitespace ignored in relative imports: from.package import something is valid syntax
New submission from Jacek Szpot: Just wanted to let you know that missing whitespace between "from" and a dot-prefixed name is not considered invalid: from.foo import bar .. does not raise an error. Perhaps it should? -- messages: 208022 nosy: maligree priority: normal severity: normal status: open title: Whitespace ignored in relative imports: from.package import something is valid syntax type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue20240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27105] cgi.__all__ is incomplete
Jacek Kołodziej added the comment: Thank you, Martin. :) -- ___ Python tracker <http://bugs.python.org/issue27105> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: Hi! This is my first attempt at contributing so as always, feedback will be well appreciated. :) I meant to start small so I took a shot with csv module. In test, initial expected set contains QUOTE_* because they don't provide __module__ attribute, and __doc/version__ because they are already in csv.__all__ (should they?). I've made a few PEP8-related fixes just around code I've touched (so they aren't completely unrelated). Is that ok? -- nosy: +Unit03 Added file: http://bugs.python.org/file39716/Issue23883_csv_all.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Jacek Kołodziej : Removed file: http://bugs.python.org/file39716/Issue23883_csv_all.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file39717/Issue23883_csv_all.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file39721/Issue23883_csv_all.v2.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file39733/Issue23883_support_check__all__.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file39734/Issue23883_test_gettext.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: Thank you for feedback, Martin. I've amended the the patch. Next, I've prepared some initial test.support.check__all__ helper, based on generalization of all previous patches. Its name/params' descriptions may be a bit rough - amendments/suggestions for such will be strongly appreciated: Issue23883_support_check__all__.patch I've added missing test.test_gettext.MiscTestCase, based on aforementioned check__all__ helper: Issue23883_test_gettext.patch I've also took the liberty of working on some more modules. These are: csv (using new helper), enum, ftplib, logging, optparse, pickletools, threading and wave: Issue23883_all.patch ftplib and threading have more functions (missing in their __all__ variables) that appear to be documented than mentioned in msg240217 - namely: * ftplib.error_temp https://docs.python.org/3/library/ftplib.html#ftplib.error_temp * ftplib.error_proto https://docs.python.org/3/library/ftplib.html#ftplib.error_proto * threading.main_thread https://docs.python.org/3/library/threading.html#threading.main_thread so I've added them as well. -- Added file: http://bugs.python.org/file39735/Issue23883_all.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: > ftplib and threading have more functions I've meant function and exceptions, of course. Sorry for the noise. -- ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: I've added previously missing test and docs for test.support.check__all__ in Issue23883_support_check__all__.v2.patch . Awaiting review. :) -- Added file: http://bugs.python.org/file39760/Issue23883_support_check__all__.v2.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file39807/Issue23883_support_check__all__.v3.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file39808/Issue23883_test_gettext.v2.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: > Nice work with the check__all__() function. Thank you! :) > I left some comments on Reitveld. Also, it currently ignores items satisfying > either of these checks: > > * isinstance(module_object, types.ModuleType) > * getattr(module_object, '__module__', None) not in name_of_module > > The first is largely redundant with the second, because module objects don’t > have a __module__ attribute. However I wonder if it would be better to drop > the second check and just rely on the ModuleType check, making the test > stricter. Or would this be too annoying in some cases (requiring a huge > blacklist)? If so, maybe make the name_of_module checking optional. Could you please elaborate on "making the test stricter"? I'd go with the first check + optional name_of_module. With second one alone, all freshly added test__all__ tests would need additional names in blacklists - not huge ones, but they would otherwise be unnecessary. I've amended the patches and I'm waiting for review. I've also thought of not only making name_of_module param optional, but to make it extra_names_of_module (so such param would be added to module.__name__ used in "getattr(module_object, '__module__', None) in name of module" check. It would account for less typing in general (module.__name__ occurs in almost all cases), but also less explicity. What do you think? -- Added file: http://bugs.python.org/file39809/Issue23883_all.v3.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file39867/Issue23883_support_check__all__.v4.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file39868/Issue23883_test_gettext.v3.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment:
> In any case it is too late for 3.5.
Ok, next round of patches is based on default branch.
> Jacek: If we used the ModuleType check, and somebody adds a module-level
> constant (like logging.CRITICAL = 50), the test will automatically detect if
> they forget to update __all__. That is what I meant by the test being
> stricter.
Right and I think such case should be covered as well. I think it may be worth
the hassle of adding new condition in detecting names expected to be
documented, so the whole if clause would look like:
if (getattr(module_object, '__module__', None) in name_of_module
or (not isinstance(module_object, types.ModuleType)
and not hasattr(module_object, '__module__'))):
expected.add(name)
Obviously tradeoff lies in required blacklisting:
* with previous __module__ check - all undocumented, non "_*" names defined in
checked module, but constants need to be in *extra* and new ones won't be
detected
* with ModuleType check only - all undocumented, non "_*" names defined in
checked module + all functions and classes imported from other modules needs
blacklisting
* with extended __module__ check (proposed above) - all undocumented, non "_*"
names defined in checked module + all constants imported from other modules;
this choice also requires less 'extra' params (in fact, in these patches only
csv.__doc/version__ case left)
In this round of patches I went the new, third way.
One odd thing: in test.test_logging, are these:
3783:self.addCleanup(setattr, logging, 'raiseExecptions', old_raise)
3790:self.addCleanup(setattr, logging, 'raiseExecptions', old_raise)
("Ex*ec*ptions") really typos or is it intentional? test.test_logging has
raiseExceptions name as well.
Also, pickletools.OpcodeInfo and threading.ThreadError are not really
documented, are they?
--
Added file: http://bugs.python.org/file39869/Issue23883_all.v4.patch
___
Python tracker
<http://bugs.python.org/issue23883>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: I'm getting patches ready with amendments you've proposed. Two things, though (and two on Rietveld): > That raiseExecptions thing looks like a typo to me. The code should probably > be monkey patching the module variable, and restoring it after the test. Then > you wouldn’t need to add your extra typoed version to the blacklist. Wouldn't it be better to just blacklist the typoed version in this patch, with proper comment, and then fix the typo along with test? Working it around like you proposed looks like unnecessary overkill. I'm also not yet sure where is the "don't change too much in one patch" border. > pickletools.OpcodeInfo: It is briefly mentioned as the type of the first item > of genops(). I don’t have a strong opinion, but I tended to agree with your > previous patch which added it to __all__. That addition was a little absentminded of me, sorry for that. Is such brief mention considered a documentation for a part of API in this case? -- ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24678] raiseExceptions typo fix in logging tests
New submission from Jacek Kołodziej: The typo in test_logging was discovered while working on #23883: in two tests the addCleanup call reverts the raiseEx*ec*ptions value (instead of raiseExceptions) in logging module and apparently that didn't manifest itself in any way. Patch attached. -- components: Tests files: test_logging_typo.patch keywords: patch messages: 247047 nosy: Unit03, vadmium, vinay.sajip priority: normal severity: normal status: open title: raiseExceptions typo fix in logging tests versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39966/test_logging_typo.patch ___ Python tracker <http://bugs.python.org/issue24678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24678] raiseExceptions typo fix in logging tests
Jacek Kołodziej added the comment: s/swapattr/swap_attr/g :) Done. -- Added file: http://bugs.python.org/file39968/test_logging_typo.v2.patch ___ Python tracker <http://bugs.python.org/issue24678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file39976/Issue23883_support_check__all__.v5.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: > raiseExecptions typo: Might be best to get the typo fixed first (maybe open a > separate issue, since it should probably be fixed starting from the 3.4 > branch). Done in #24678 and commited in 83b45ea19d00 . > Regarding OpcodeInfo, it is probably up to your judgement. Then I'll leave it as it was - without OpcodeInfo in pickletools.__all__ . The test for it remains in the patch, though. -- Added file: http://bugs.python.org/file39977/Issue23883_all.v5.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: Does anyone have strong preference towards one of the propositions above? TestCase subclass looks reasonable IMHO, but I'd not add that to the scope of this issue (I'd be happy to implement it later, though). Any suggestions? -- ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file41012/Issue23883_all.v6.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: Serhiy, thank you for the review. I've made proposed changes (along with rebasing Issue23883_all patch; Issue23883_test_gettext.v3.patch still applies cleanly). -- Added file: http://bugs.python.org/file41013/Issue23883_support_check__all__.v6.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: Martin, yay! :) And thank you for the documentation correction. Milap, Joel, Mauro, are you still interested in working on patches for calendar/tarfile/fileinput patches? I intend to finish them up if that's not the case. -- ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: Week and no response, I'm posting updated patches for calendar and tarfile. -- Added file: http://bugs.python.org/file41118/Issue23883_tarfile_all.v2.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file41117/Issue23883_calendar_all.v2.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25975] Weird multiplication
Jacek Kołodziej added the comment: LCK: it's a trait of float point arithmetic in computing: https://docs.python.org/3.5/tutorial/floatingpoint.html . It's not a bug. -- nosy: +Unit03 ___ Python tracker <http://bugs.python.org/issue25975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26794] curframe can be None in pdb.py
New submission from Jacek Pliszka: In /usr/lib64/python2.7/pdb.py in Pdb.default there is line: globals = self.curframe.f_globals curframe can be None so the line should be replaced by: globals = getattr(self.curframe, "f_globals", None) if hasattr(self, 'curframe') else None or something should be done in different way in setup -- components: Library (Lib) messages: 263652 nosy: Jacek.Pliszka priority: normal severity: normal status: open title: curframe can be None in pdb.py type: crash versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue26794> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27105] cgi.__all__ is incomplete
New submission from Jacek Kołodziej: That's a child issue of #23883, created to propose a patch fixing cgi module's __all__ list. -- components: Library (Lib) files: cgi_all.patch keywords: patch messages: 266265 nosy: Unit03 priority: normal severity: normal status: open title: cgi.__all__ is incomplete type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42967/cgi_all.patch ___ Python tracker <http://bugs.python.org/issue27105> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27106] configparser.__all__ is incomplete
New submission from Jacek Kołodziej: That's a child issue of #23883, created to propose a patch fixing configparser module's __all__ list. -- components: Library (Lib) files: configparser_all.patch keywords: patch messages: 266266 nosy: Unit03 priority: normal severity: normal status: open title: configparser.__all__ is incomplete type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42968/configparser_all.patch ___ Python tracker <http://bugs.python.org/issue27106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27107] mailbox.__all__ list is incomplete
New submission from Jacek Kołodziej: That's a child issue of #23883, created to propose a patch fixing mailbox module's __all__ list. -- components: Library (Lib) files: mailbox_all.patch keywords: patch messages: 266267 nosy: Unit03 priority: normal severity: normal status: open title: mailbox.__all__ list is incomplete type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42969/mailbox_all.patch ___ Python tracker <http://bugs.python.org/issue27107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27108] mimetypes.__all__ list is incomplete
New submission from Jacek Kołodziej: That's a child issue of #23883, created to propose a patch fixing mimetypes module's __all__ list. -- components: Library (Lib) files: mimetypes_all.patch keywords: patch messages: 266268 nosy: Unit03 priority: normal severity: normal status: open title: mimetypes.__all__ list is incomplete type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42970/mimetypes_all.patch ___ Python tracker <http://bugs.python.org/issue27108> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27109] plistlib.__all__ list is incomplete
New submission from Jacek Kołodziej: That's a child issue of #23883, created to propose a patch fixing plistlib module's __all__ list. -- components: Library (Lib) files: plistlib_all.patch keywords: patch messages: 266269 nosy: Unit03 priority: normal severity: normal status: open title: plistlib.__all__ list is incomplete type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42971/plistlib_all.patch ___ Python tracker <http://bugs.python.org/issue27109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27110] smtpd.__all__ list is incomplete
New submission from Jacek Kołodziej: That's a child issue of #23883, created to propose a patch fixing smtpd module's __all__ list. -- components: Library (Lib) files: smtpd_all.patch keywords: patch messages: 266270 nosy: Unit03 priority: normal severity: normal status: open title: smtpd.__all__ list is incomplete type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42972/smtpd_all.patch ___ Python tracker <http://bugs.python.org/issue27110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27110] smtpd.__all__ list is incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file42977/smtpd_all.patch ___ Python tracker <http://bugs.python.org/issue27110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27112] tokenize.__all__ list is incomplete
New submission from Jacek Kołodziej: That's a child issue of #23883, created to propose a patch fixing tokenize module's __all__ list. Changes in tests go farther: I've changed import from from tokenize import ... to import tokenize and adjusted all its usages accordingly. The module must be imported in order to test its __all__ list through test.support.check__all__ helper and just adding this single import would either force us to either do * import tokenize as tokenize_module * or from tokenize import tokenize as tokenize_function I think going third way: with just "import tokenize" and changing its uses in the rest of tests result in celarer code, but of course I guess this may be too much for a single patch. -- components: Library (Lib) files: tokenize_all.patch keywords: patch messages: 266275 nosy: Unit03 priority: normal severity: normal status: open title: tokenize.__all__ list is incomplete type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42976/tokenize_all.patch ___ Python tracker <http://bugs.python.org/issue27112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27110] smtpd.__all__ list is incomplete
Changes by Jacek Kołodziej : Removed file: http://bugs.python.org/file42972/smtpd_all.patch ___ Python tracker <http://bugs.python.org/issue27110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: Per Martin's request, I've created a few new issues for next batch of module's __all__ list updates: * cgi: #27105 * configparser: #27106 * mailbox: #27107 * mimetypes: #27108 * plistlib: #27109 * smtpd: #27110 * tokenize: #27112 I've also looked at pydoc module, but I'm not sure what to do with it: `doc` function has only a brief docstring, it's not mentioned in docs at all. Should it really be in pydoc.__all__? -- ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27107] mailbox.__all__ list is incomplete
Jacek Kołodziej added the comment: David, what do you mean by "new format"? Can you point me to some existing code? -- ___ Python tracker <http://bugs.python.org/issue27107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27105] cgi.__all__ is incomplete
Jacek Kołodziej added the comment: Well, but it is documented in public docs: cgi.test() Robust test CGI script, usable as main program. Writes minimal HTTP headers and formats all information provided to the script in HTML form. Should I remove it from __all__ and probably from the docs, too? -- ___ Python tracker <http://bugs.python.org/issue27105> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27112] tokenize.__all__ list is incomplete
Jacek Kołodziej added the comment: I disagree: * blacklist has 48 entries now, whitelist would have 72 ones * whitelisting requires adding new public names to two places instead of one * test.support.check__all__ currently don't support whitelisting, it would need to be added -- ___ Python tracker <http://bugs.python.org/issue27112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27108] mimetypes.__all__ list is incomplete
Jacek Kołodziej added the comment: Thank you, Martin. I'm uploading amended patch. -- Added file: http://bugs.python.org/file42988/mimetypes_all.v2.patch ___ Python tracker <http://bugs.python.org/issue27108> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27105] cgi.__all__ is incomplete
Jacek Kołodziej added the comment: Martin: > Is there any advantage to having the test case in a separate MiscTestCase > class, as opposed to the existing CgiTests class? Other than "the first test [well, that I know of] for __all__ list was in separate class called MiscTestCase so each next one follows the same fashion" and "sometimes such test would fit into some existing TestCase class and sometimes not, so let's always put it into separate class for cohesion" - no, I don't see any. -- ___ Python tracker <http://bugs.python.org/issue27105> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Jacek Kołodziej added the comment: In this case I'm proposing a small patch just for testing pydoc module's __all__ list and left the decision to you, whether to apply it or not. :) Test doesn't use test.support.check__all__ (see msg266312) - blacklist would be huge and expected list, as you already pointed out, has only one value. -- Added file: http://bugs.python.org/file43002/Issue23883_pydoc_all.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27112] tokenize.__all__ list is incomplete
Jacek Kołodziej added the comment: > * All names in black list are implementation details. Names in white list are > stable and already repeated in docs. Assumption here is that implementation details shouldn't "look" public - they should have names starting with "_"; I think blacklisting names in these tests encourages good practice - if something "looks" public, either: * it should be documented and placed in __all__ * renamed to something that doesn't look public anymore * in some special cases - be explicitely blacklisted in test. But ok, assuming we go with whitelisting and plain self.assertCountEqual: > * White list consists mostly from token.__all__. Should I then do: import token expected = token.__all__ + ["COMMENT", "NL", "ENCODING", "TokenInfo", "TokenError", "detect_encoding", "untokenize", "open", "tokenize"] ? > IMO changing all the names adds too much churn with minimal benefit. I wouldn't call it minimal, it has some positive impact on readability, see last line from The Zen of Python. :) Of course, final call is yours. Single import of unittest is such a small change I would rather keep it. I fully agree existing TestMisc class is a good place for this test, though. -- ___ Python tracker <http://bugs.python.org/issue27112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27106] configparser.__all__ is incomplete
Jacek Kołodziej added the comment: Łukasz, Martin - I'm not sure how to proceed here, of course both ways out are reasonable. I'd be happy to provide (however small) patch for either one (adding Error to __all__ or just adding test for __all__). :) My inner librarian would of course either push the Error to fully become part of public API or change its name to non-public _Error or something, but I'd much rather rely on you in this regard. -- ___ Python tracker <http://bugs.python.org/issue27106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27112] tokenize.__all__ list is incomplete
Changes by Jacek Kołodziej : Added file: http://bugs.python.org/file44373/tokenize_all.v2.patch ___ Python tracker <http://bugs.python.org/issue27112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27112] tokenize.__all__ list is incomplete
Jacek Kołodziej added the comment: > I would lean toward ensuring the test fails if someone adds a new > implementation detail without an underscore prefix. It is also good to be > explicit that the ISTERMINAL() etc functions are special cases. Original patch meets these requirements. I've updated it with moving the test__all__ method to TestMisc class as suggested (tokenize_all.v2.patch). I'm also attaching the alternative version (tokenize_all.v2.1.patch) that uses self.assertCountEqual instead of support.check__all__ and whitelisting as Serhiy suggested; this version of test doesn't meet the requirements above. Yes, neither one challenge the tok_name (#25324) problem, I'm not really sure whether is should, though. I'll try to solve it with separate patch if I find some time. -- Added file: http://bugs.python.org/file44374/tokenize_all.v2.1.patch ___ Python tracker <http://bugs.python.org/issue27112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27106] configparser.__all__ is incomplete
Jacek Kołodziej added the comment: That's completely fine for me. I'm attaching the patch that just adds test for __all__, then. :) -- Added file: http://bugs.python.org/file44393/configparser_all.v2.patch ___ Python tracker <http://bugs.python.org/issue27106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
