[issue21289] make.bat not building documentation
New submission from Dave Sawyer: With Python 3.5, some refactoring of the documentation structure has been done. Building the documentation targets directly works, but using the supplied make.bat fails, not finding the sphinx python file. -- assignee: docs@python components: Documentation messages: 216737 nosy: docs@python, dsawyer priority: normal severity: normal status: open title: make.bat not building documentation type: compile error versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue21289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21289] make.bat not building documentation
Changes by Dave Sawyer : -- type: compile error -> behavior ___ Python tracker <http://bugs.python.org/issue21289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21289] make.bat not building documentation
Changes by Dave Sawyer : -- keywords: +patch Added file: http://bugs.python.org/file34954/mywork.patch ___ Python tracker <http://bugs.python.org/issue21289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21289] make.bat not building documentation
Dave Sawyer added the comment: Removed the use of python in the make, calling the sphinx-build executable. Also the Doc directory was called "Docs" in the readme.txt -- ___ Python tracker <http://bugs.python.org/issue21289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15414] os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented
Dave Sawyer added the comment:
http://bugs.python.org/issue1669539 has been partially fixed. On Windows
os.path.join('foo', 'a:bar') gives 'a:bar' not 'foo\\a:bar'. However
os.path.isabs('a:bar') returns False yet it causes a reset in the join like an
absolute path.
'\foo' is considered an absolute path even though calling os.path.abspath on it
can yield different results - as if it were a relative path. At minimum we
should amend the wording about what resets the join.
--
nosy: +dsawyer
___
Python tracker
<http://bugs.python.org/issue15414>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15414] os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented
Changes by Dave Sawyer : -- keywords: +patch Added file: http://bugs.python.org/file34956/joindoc.patch ___ Python tracker <http://bugs.python.org/issue15414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15414] os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented
Changes by Dave Sawyer : -- versions: +Python 3.4, Python 3.5 -Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue15414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21289] make.bat not building documentation
Changes by Dave Sawyer : Added file: http://bugs.python.org/file34957/mywork.patch ___ Python tracker <http://bugs.python.org/issue21289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21289] make.bat not building documentation
Dave Sawyer added the comment: Thanks Zach! The bug tracker was nice enough to prompt me to go look in my email for the agreement too. -- ___ Python tracker <http://bugs.python.org/issue21289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21289] make.bat not building documentation
Dave Sawyer added the comment: Thanks Zach, I'm used to Git and this was my first foray with Hg and trying to rebase (I knew I shoulda branched before starting on another patch). BTW, the devs at PyCon Montreal said "Zach's a good guy. One of maybe 4 Windows devs." -Dave -- ___ Python tracker <http://bugs.python.org/issue21289> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27113] sqlite3 connect parameter "check_same_thread" not documented
Dave Sawyer added the comment: The revised patch says "connections" plural for true and "connection" singular for false. How about "the connection" since the method returns a connection. I'm wondering though about the lack of explanation or WHY for this parameter. As written it seems like the default value was poorly chosen and everyone should just set it to true. Likewise, if everyone should set it to true, why is it even provided as an option? -- ___ Python tracker <http://bugs.python.org/issue27113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27113] sqlite3 connect parameter "check_same_thread" not documented
Dave Sawyer added the comment: The user probably has a recent enough version. This is guaranteed on Windows since Python bundles 3.6 or later. On mac or Linux it will use the version installed on the machine. I'll make a separate patch to check the version in sqlite3.py so it will give an error if attempted on too early a version. That's better than asking the user to verify ahead of time. The serialized mode is default on both Mac and Windows so we can probably skip validating that. I did like mentioning the user needs to serialize the writes. They could use one thread for writing only or use locking. So, I just said to serialize. -- Added file: http://bugs.python.org/file43116/sqlite_patch2.txt ___ Python tracker <http://bugs.python.org/issue27113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27113] sqlite3 connect parameter "check_same_thread" not documented
Dave Sawyer added the comment: Changed doc to note that not only must it be used on 1 thread if true, but that thread must be the thread that created it. -- ___ Python tracker <http://bugs.python.org/issue27113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27188] sqlite3 execute* methods return value not documented
New submission from Dave Sawyer: The three execute methods of the connection object return the created cursor. The term "intermediate" implies the cursor is totally handled by the execute method, not that the user will get ownership of the object. When the user doesn't call close() on the returned cursor right away, they hold a lock on the database until the object is garbage collected. -- files: execdoc_patch1.txt messages: 266964 nosy: Dave Sawyer priority: normal severity: normal status: open title: sqlite3 execute* methods return value not documented type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43120/execdoc_patch1.txt ___ Python tracker <http://bugs.python.org/issue27188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27113] sqlite3 connect parameter "check_same_thread" not documented
Dave Sawyer added the comment: Hi Thomas and Senthil, for the serialized setting I mentioned earlier "The serialized mode is default on both Mac and Windows so we can probably skip validating that. I did like mentioning the user needs to serialize the writes. They could use one thread for writing only or use locking. So, I just said to serialize." to go into more detail, when serialize is set you don't need to worry that using multiple threads will WRECK your database. But, you still need to make sure your own writes get serialized or you will mix transactions together. Each connection only has one transaction in progress so if you share that connection between threads... watch out for your writes. Now if only one thread in your application writes and the other threads read you have no serialization issues to worry about. If two threads make updates without a threading.Lock than you can get 1.5 changes committed (and perhaps 0.5 later or if that had an error you might rollback that 0.5 of a transaction). You could also get the first thread to commit both changes and when the later thread calls commit get an error that is "no transaction in progress." I thought "serialize" neatly encapsulated the two most common strategies here for shared connections - either a dedicated writer thread or using a python lock around your transactions. As Thomas points out you can also opt to give each thread its own connection... but then you don't need the check_same_thread parameter set to False as you are not sharing the connection. -- ___ Python tracker <http://bugs.python.org/issue27113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27190] Check sqlite3_version before allowing check_same_thread = False
New submission from Dave Sawyer: Starting in sqlite version 3.3.1 (Jan 2006) multiple threads can share the same connection. Python allows you do use this with the check_same_thread parameter of sqlite3.connect() method. It's almost certain users have a late enough version of sqlite that they can use this option. While we could document "check your version before using this feature" (see http://bugs.python.org/issue27113) it would be nicer to check the actual database for support. Code can be written and tested on one machine and deployed to another machine. Using this feature on an very old version of sqlite can crash or possibly corrupt the database. -- files: sqlite_oldver_issue.txt messages: 267013 nosy: Dave Sawyer priority: normal severity: normal status: open title: Check sqlite3_version before allowing check_same_thread = False type: enhancement Added file: http://bugs.python.org/file43135/sqlite_oldver_issue.txt ___ Python tracker <http://bugs.python.org/issue27190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27190] Check sqlite3_version before allowing check_same_thread = False
Dave Sawyer added the comment: This can go into bugfix branches. In fact, it's most likely to be helpful there because they are more likely to be running with a version of sqlite 10 years old. I use the sqlite3_libversion_number() call because I'm testing against the version of sqlite actually loaded. The SQLITE_VERSION_NUMBER define is set at compile time. -- Added file: http://bugs.python.org/file43161/issue27190_patch2.txt ___ Python tracker <http://bugs.python.org/issue27190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27113] sqlite3 connect parameter "check_same_thread" not documented
Dave Sawyer added the comment: hurray! My first commit -- ___ Python tracker <http://bugs.python.org/issue27113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27188] sqlite3 execute* methods return value not documented
Dave Sawyer added the comment: Updated optional parameters. Fixed executescript which takes a single parameter. The English is correct - one needs to looks at the verbs to be sure they match in tense and number. Like "He OPENS the fridge, GRABS the milk, and DRINKS it." This method CREATES a cursor, CALLS the method, and RETURNS the cursor. -- Added file: http://bugs.python.org/file43269/issue27188_patch2.txt ___ Python tracker <http://bugs.python.org/issue27188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27188] sqlite3 execute* methods return value not documented
Dave Sawyer added the comment: No problem. I did a pull and reposted with additional fixes suggested by Berker and one copy/paste error I spotted. On Sat, Jun 4, 2016 at 11:34 PM, SilentGhost wrote: > > SilentGhost added the comment: > > Thanks for the patch, Dave. For whatever reason it doesn't seem to apply > cleanly to the current tip, would you mind preparing a new patch that does? > > -- > assignee: -> docs@python > components: +Documentation > nosy: +SilentGhost, berker.peksag, docs@python, ghaering > stage: -> patch review > type: enhancement -> behavior > > ___ > Python tracker > <http://bugs.python.org/issue27188> > ___ > -- ___ Python tracker <http://bugs.python.org/issue27188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27113] sqlite3 open parameter "check_same_thread" not documented
New submission from Dave Sawyer: The sqlite3.connect method has 6 parameters. 5 of them are documented. See below and search for "check_same_thread". Patch adds documentation for this parameter. sqlite3.connect(database[, timeout, detect_types, isolation_level, check_same_thread, factory, cached_statements]) Opens a connection to the SQLite database file database. You can use ":memory:" to open a database connection to a database that resides in RAM instead of on disk. When a database is accessed by multiple connections, and one of the processes modifies the database, the SQLite database is locked until that transaction is committed. The timeout parameter specifies how long the connection should wait for the lock to go away until raising an exception. The default for the timeout parameter is 5.0 (five seconds). For the isolation_level parameter, please see the Connection.isolation_level property of Connection objects. SQLite natively supports only the types TEXT, INTEGER, REAL, BLOB and NULL. If you want to use other types you must add support for them yourself. The detect_types parameter and the using custom converters registered with the module-level register_converter() function allow you to easily do that. detect_types defaults to 0 (i. e. off, no type detection), you can set it to any combination of PARSE_DECLTYPES and PARSE_COLNAMES to turn type detection on. By default, the sqlite3 module uses its Connection class for the connect call. You can, however, subclass the Connection class and make connect() use your class instead by providing your class for the factory parameter. Consult the section SQLite and Python types of this manual for details. The sqlite3 module internally uses a statement cache to avoid SQL parsing overhead. If you want to explicitly set the number of statements that are cached for the connection, you can set the cached_statements parameter. The currently implemented default is to cache 100 statements. -- assignee: docs@python components: Documentation files: doc_parm.patch keywords: patch messages: 266281 nosy: Dave Sawyer, docs@python priority: normal severity: normal status: open title: sqlite3 open parameter "check_same_thread" not documented type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42978/doc_parm.patch ___ Python tracker <http://bugs.python.org/issue27113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27113] sqlite3 connect parameter "check_same_thread" not documented
Changes by Dave Sawyer : -- title: sqlite3 open parameter "check_same_thread" not documented -> sqlite3 connect parameter "check_same_thread" not documented ___ Python tracker <http://bugs.python.org/issue27113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6818] remove/delete method for zipfile/tarfile objects
Dave Sawyer added the comment: I'd be interested in taking up the zip portion at Pycon 2015 this year. I recently had need to delete file(s) from a zipfile. To do it today with the existing API requires you to unpack the zip and repack it. The unpack is slow and you need enough free disk space for the uncompressed files. My strategy is essentially exactly what msg229893 2a said: copy binary blobs to a tempfile, then overwrite the original when complete. I would use a name filter function to decide what to delete and optional parameter for the temp file (falling back to tempfile.tempfile if None). IIRC, this is the same strategy used in the dotNet zip library. -- nosy: +Dave Sawyer ___ Python tracker <http://bugs.python.org/issue6818> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6818] remove/delete method for zipfile/tarfile objects
Dave Sawyer added the comment: The zipfile way to delete or rename would be to just change the index. It really doesn't want to be re-written as it is designed to span disks. Many old versions of files can be scattered within the zip. In addition self-extracting zip files will have executable code in the front of the zip. To make a zip smaller, it's desirable to have a filter function. There were points brought up about zip with overlapping data blocks (and you could envision saving space by having many identical files share the same compressed block... but this is not legal zip. A file info header block must precede EACH individual file data block. This is brought home by there being only a length field in the info header. -- Added file: http://bugs.python.org/file39061/mywork.patch ___ Python tracker <http://bugs.python.org/issue6818> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6818] remove/delete method for zipfile/tarfile objects
Dave Sawyer added the comment: I can add some more tests to bring up the coverage, but wanted to get reviewer opinion on the direction of this before doing more work. -- hgrepos: +305 Added file: http://bugs.python.org/file39063/zipfile_filter.patch ___ Python tracker <http://bugs.python.org/issue6818> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6818] remove/delete method for zipfile/tarfile objects
Dave Sawyer added the comment: Maybe it takes a little longer than a week. I have a final signed agreement from Ewa (https://secure.echosign.com/public/viewAgreement?aid=X88L4EVP5IXC289&eid=X88M6DGQ93J5K38&;) signed on 04/17/2014 6:48 PM Wow, exactly one year ago! -- ___ Python tracker <http://bugs.python.org/issue6818> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
