[issue24641] Log type of unserializable value when raising JSON TypeError
New submission from Madison May:
Currently the json lib only logs the string representation of the variable,
which does not always include type information.
I recently ran into a difficult to debug issue with code similar to the
following:
```
import json
import numpy as np
d = {'data': np.int16(5)}
json.dumps(d)
```
which produces the following error:
```
TypeError: 5 is not JSON serializable
```
It took us quite a while to determine that `5` was actually of type `np.int`
instead of the native type.
A cursory glance at StackOverflow suggests that I'm not alone in running into
this issue:
http://stackoverflow.com/questions/10872604/json-dump-throwing-typeerror-is-not-json-serializable-on-seemingly-vali
I'd like to consider modifying the error message to be more similar to the
following:
```
TypeError: 5 of type `numpy.int16` is not JSON serializable
```
--
components: Library (Lib)
messages: 246776
nosy: Madison May
priority: normal
severity: normal
status: open
title: Log type of unserializable value when raising JSON TypeError
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24641
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24396] Provide convenience function for paths relative to the current module
New submission from Madison May: I often find myself trying to access a file relative to the module I'm working on. When this occurs, I'll often use something like the following: ``` os.path.abspath(os.path.join(os.path.dirname(__file__), data/resource.pkl)) ``` I have good reason to believe that I'm not the only one, as searching for other examples of this code on github returns ~20k exact matches: https://github.com/search?utf8=%E2%9C%93q=%22os.path.abspath%28os.path.join%28os.path.dirname%28__file__%29%22+type=Coderef=searchresults Low priority, but a more concise way of achieving the same result would be much appreciated. -- components: Library (Lib) messages: 244920 nosy: madison.may priority: normal severity: normal status: open title: Provide convenience function for paths relative to the current module type: enhancement versions: Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24396 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21202] Naming a file` io.py` causes cryptic error message
Changes by Madison May madison@students.olin.edu: -- versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21202 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21202] Naming a file` io.py` causes cryptic error message
New submission from Madison May: Naming a file `io.py` in the root directory of a project causes the following error on 2.7: AttributeError: 'module' object has no attribute 'BufferedIOBase' Similar issues arise on 3.x., although the error message is a bit more useful: Fatal Python error: Py_Initialize: can't initialize sys standard streams AttributeError: 'module' object has no attribute 'OpenWrapper' At the very least we should ensure that the error message is a bit more straightforward and clear, as I imagine its not all that uncommon to cause this kind of conflict. -- assignee: docs@python components: Documentation, IO messages: 215940 nosy: docs@python, madison.may priority: normal severity: normal status: open title: Naming a file` io.py` causes cryptic error message versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21202 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21202] Naming a file` io.py` causes cryptic error message
Madison May added the comment: I definitely agree that io shouldn't be special cased, as it's more about the name shadowing issue that this specific example. A simple docs addition would make me happy, to be honest. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21202 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21145] Add the @cached_property decorator
Madison May added the comment: There's currently an example of a cached property decorator implementation in the wiki, although it doesn't leverage functools: https://wiki.python.org/moin/PythonDecoratorLibrary#Cached_Properties -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21145 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20063] Docs imply that set does not support .pop() method
New submission from Madison May: Note item 6 of http://docs.python.org/2.7/library/stdtypes.html#mutable-sequence-types is a bit misleading. It states: The pop() method is only supported by the list and array types. The optional argument i defaults to -1, so that by default the last item is removed and returned. However, pop() is also a method of sets, which are neither lists or arrays. -- assignee: docs@python components: Documentation messages: 206899 nosy: docs@python, madison.may priority: normal severity: normal status: open title: Docs imply that set does not support .pop() method versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20063 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20063] Docs imply that set does not support .pop() method
Madison May added the comment: +1 for simply deleting that bit -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20063 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Madison May added the comment: You have me convinced, Serhiy. I see the value in making the two functions distinct. For naming purposes, perhaps weighted_index() would be more descriptive. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Madison May added the comment: Serhiy, from a technical standpoint, your latest patch looks like a solid solution. From an module design standpoint we still have a few options to think through, though. What if random.weighted_choice_generator was moved to random.choice_generator and refactored to take an array of weights as an optional argument? Likewise, random.weighted_choice could still be implemented with an optional arg to random.choice. Here's the pros and cons of each implementation as I see them. Implementation: weighted_choice_generator + weighted_choice Pros: Distinct functions help indicate that weighted_choice should be used in a different manner than choice -- [weighted_choice(x) for _ in range(n)] isn't efficient. Can take Mapping or Sequence as argument. Has a single parameter Cons: Key, not value, is returned Requires two new functions Dissimilar to random.choice Long function name (weighted_choice_generator) Implementation: choice_generator + optional arg to choice Pros: Builds on existing code layout Value returned directly Only a single new function required More compact function name Cons: Difficult to support Mappings Two args required for choice_generator and random.choice Users may use [choice(x, weights) for _ in range(n)] expecting efficient results -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19024] Document asterisk (*), splat or star operator
Madison May added the comment: http://docs.python.org/3/tutorial/controlflow.html#arbitrary-argument-lists http://docs.python.org/3/tutorial/controlflow.html#unpacking-argument-lists The above links do a so-so of explaining the splat operator, although I agree that the docs for '*' could be improved. -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19024 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Madison May added the comment: I think Storchaka's solution is more transparent and I agree with him on the point that the choice generator should be exposed. Valid point -- transparency should be priority #1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18800] Document Fraction's numerator and denominator properties
Madison May added the comment: Simple and to the point. Sounds good to me... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18800 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18856] Added test coverage for calendar print functions
Madison May added the comment: At Ezio suggestion, I've updated the patch to use test.support.captured_stdout(). -- Added file: http://bugs.python.org/file31611/calendar_print_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18856 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18828] urljoin behaves differently with custom and standard schemas
Madison May added the comment:
If nothing else, we should document the work around for this issue.
import urllib.parse
urllib.parse.uses_relative.append('redis')
urllib.parse.uses_netloc.append('redis')
urllib.parse.urljoin('redis://localhost:6379/0', '/1')
'redis://localhost:6379/1'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18828
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18828] urljoin behaves differently with custom and standard schemas
Madison May added the comment: How about adding a codecs.register like public API for 3.4+? A codecs style register function seems like an excellent solution to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18893] invalid exception handling in Lib/ctypes/macholib/dyld.py
Madison May added the comment: Seems like a simple fix -- patch attached. -- keywords: +patch nosy: +madison.may Added file: http://bugs.python.org/file31560/issue18893.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18893 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Madison May added the comment: [Raymond Hettinger] The sticking point is going to be that we don't want to recompute the cumulative weights for every call to weighted_choice. So there should probably be two functions: cw = make_cumulate_weights(weight_list) x = choice(choice_list, cw) That's pretty much how I broke things up when I decided to test out optimization with lru_cache. That version of the patch is now attached. [Serhiy Storchaka] I like the idea about adding a family of distribution generators. They should check input parameters and make a precomputation and then generate infinite sequence of specially distributed random numbers. Would these distribution generators be implemented internally (see attached patch) or publicly exposed? -- Added file: http://bugs.python.org/file31546/weighted_choice_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Changes by Madison May madison@students.olin.edu: Removed file: http://bugs.python.org/file31546/weighted_choice_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Changes by Madison May madison@students.olin.edu: Added file: http://bugs.python.org/file31547/weighted_choice_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Madison May added the comment: Use lru_cache isn't good because several choice generators can be used in a program and because it left large data in a cache long time after it was used. Yeah, I just did a quick search of the stdlib and only found one instance of lru_cache in use -- another sign that lru_cache is a bad choice. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18900] Add the random.distrib module
Madison May added the comment:
I like the core idea of a family of random generators, but it feels like a new
module that's nearly identical to random introduces a lot of repeated code.
Perhaps adding an additional optional arg ('generator=False', for example) to
these functions in the random module would be a bit simpler.
--
nosy: +madison.may
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18900
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Madison May added the comment: What do R, SciPy, Fortran, Matlab or other statistical packages already do? Numpy avoids recalculating the cumulative distribution by introducing a 'size' argument to numpy.random.choice(). The cumulative distribution is calculated once, then 'size' random choices are generated and returned. Their overall implementation is quite similar to the method suggested in the python docs. choices, weights = zip(*weighted_choices) cumdist = list(itertools.accumulate(weights)) x = random.random() * cumdist[-1] choices[bisect.bisect(cumdist, x)] The addition of a 'size' argument to random.choice() has already been discussed (and rejected) in Issue18414, but this was on the grounds that the standard idiom for generating a list of random choices ([random.choice(seq) for i in range(k)]) is obvious and efficient. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18900] Add the random.distrib module
Madison May added the comment: ...we can turn current functions in the random module into wrappers around generators from the distrib module. Makes sense. In light of Raymond's comments on code bloat in issue18844, perhaps this module could be added to PyPi to see whether or not there's interest in this kind of functionality? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Madison May added the comment: Just ran across a great blog post on the topic of weighted random generation from Eli Bendersky for anyone interested: http://eli.thegreenplace.net/2010/01/22/weighted-random-generation-in-python/ -- nosy: +eli.bendersky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18888] Add stdlib support for random sampling with replacement
Madison May added the comment: Whoops, my apologies. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Madison May added the comment: [Mark Dickinson] Both those seem like clear error conditions to me, though I think it would be fine if the second condition produced a ZeroDivisionError rather than a ValueError. Yeah, in hindsight it makes sense that both of those conditions should raise errors. After all: Explicit is better than implicit. As far as optimization goes, could we potentially use functools.lru_cache to cache the cumulative distribution produced by the weights argument and optimize repeated sampling? Without @lru_cache: timeit.timeit(x = choice(list(range(100)), list(range(100))), setup=from random import choice, number=10) 36.7109281539997 With @lru_cache(max=128): timeit.timeit(x = choice(list(range(100)), list(range(100))), setup=from random import choice, number=10) 6.6788657720007905 Of course it's a contrived example, but you get the idea. Walker's aliasing method looks intriguing. I'll have to give it a closer look. I agree that an efficient implementation would be preferable but would feel out of place in random because of the return type. I still believe a relatively inefficient addition to random.choice would be valuable, though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18853] Got ResourceWarning unclosed file when running Lib/shlex.py demo
Madison May added the comment: The patch LGTM as well. ResourceWarning was silenced after applying patch when tested on my machine. -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18853 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18888] Add stdlib support for random sampling with replacement
New submission from Madison May: Although the random module supports random sampling without replacement, there is no support for random sampling with replacement. Efficient random sampling with replacement is trivial using random.choice() (see below), but supporting it as an optional 'replace' arg to random.sample() might be nice for symmetry. array = range(100) random_sample = [random.choice(array) for i in range(10)] -- components: Library (Lib) messages: 196603 nosy: madison.may priority: normal severity: normal status: open title: Add stdlib support for random sampling with replacement type: enhancement versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14075] argparse: unused method?
Madison May added the comment: Any chance this issue could be reopened? I ran across this bit of code today when working on coverage for argparse. I'd like to again propose the removal or modification of _get_args. I understand that it's there primarily to be overridden, but even that's not useful. Because _get_kwargs uses obj.__dict__.items(), overriding _get_args to return an iterable of positional args results in those arguments being output twice when repr() is called (once formatted as a positional arg and once formatted as a keyword arg). You end up with strings like the below. I just can't think of any situation where this behavior would be desirable. Action(['--foo', '-a', '-b'], 'b', option_strings=['--foo', '-a', '-b'], dest='b', nargs='+', const=None, default=42, type='int', choices=[1, 2, 3], help='HELP', metavar='METAVAR') -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18550] internal_setblocking() doesn't check return value of fcntl()
Madison May added the comment: The attached patch? :) -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18550 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18828] urljoin behaves differently with custom and standard schemas
Changes by Madison May madison@students.olin.edu: -- components: +Library (Lib) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18800] Document Fraction's numerator and denominator properties
Madison May added the comment: The docs page does mention, however, that Fraction inherits from numbers.Rational, and links to that page (http://docs.python.org/2/library/numbers.html#numbers.Rational). There the properties 'numerator' and 'denominator' are clearly documented. Perhaps its still worth it to mention those properties on the Fraction docs page though, or to include them in one of the examples. -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18855] Inconsistent README filenames
New submission from Madison May: Is there any reason (other than backwards compatibility) that the names of README files are inconsistent? README: 3 instances - root, /Mac, /Misc, /Tools readme.txt: 2 instances - /PC, /PCbuild README.txt: 1 instance - /Doc -- assignee: docs@python components: Documentation messages: 196299 nosy: docs@python, madison.may priority: normal severity: normal status: open title: Inconsistent README filenames ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18855 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18856] Added test coverage for calendar print functions
New submission from Madison May: Just redirected stdout to a string io object unittest.mock.patch() to add basic test coverage for calendar.py print functions (TextCalendary.prweek(), TextCalendar.prmonth(), TextCalendar.pryear(), and format()). -- components: Tests files: calendar_print.diff keywords: patch messages: 196311 nosy: madison.may priority: normal severity: normal status: open title: Added test coverage for calendar print functions type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file31487/calendar_print.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18856] Added test coverage for calendar print functions
Madison May added the comment: ...to a string io object USING unittest.mock.patch()... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18855] Inconsistent README filenames
Madison May added the comment: It's obviously low priority, just thought I would mention it. I found it a bit odd that README is used, though, since that means users will likely have to select the program they want to use to open the file (in Windows, at least). It might also be nice to follow the standard distutils idiom. From Éric Araujo on issue11913, In packaging/distutils2, the recommended idiom looks like this (in setup.cfg): [metadata] description-file = README.whatever In other words, README.txt would work nicely. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18855 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18828] urljoin behaves differently with custom and standard schemas
Madison May added the comment: From urllib.parse: uses_relative = ['ftp', 'http', 'gopher', 'nntp', 'imap', 'wais', 'file', 'https', 'shttp', 'mms', 'prospero', 'rtsp', 'rtspu', '', 'sftp', 'svn', 'svn+ssh'] From urllib.parse.urljoin (scheme='redis' and url='/1' in your example): if scheme != bscheme or scheme not in uses_relative: return _coerce_result(url) Should the 'redis' scheme be added to uses_relative, perhaps? -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Madison May added the comment: +1. I've found myself in need of this feature often enough to wonder why it's not part of the stdlib. -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18844] allow weights in random.choice
Madison May added the comment: I realize its probably quite early to begin putting a patch together, but here's some preliminary code for anyone interested. It builds off of the common task example in the docs and adds in validation for the weights list. There are a few design decisions I'd like to hash out. In particular: - Should negative weights cause a ValueError to be raised, or should they be converted to 0s? - Should passing a list full of zeros as the weights arg raise a ValueError or be treated as if no weights arg was passed? -- keywords: +patch Added file: http://bugs.python.org/file31479/weighted_choice.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18826] reversed() requires a sequence - Could work on any iterator?
Madison May added the comment: Reversed doesn't make sense for all iterables. a = set([1, 2, 3]) a = iter(a) # No error a = reversed(a) # Not typically desirable The point is that not all iterables are necessarily ordered. And a reversed function shouldn't operate on unordered types. Here's the relevant section of the docs for reversed(): reversed(seq) Return a reverse iterator. seq must be an object which has a __reversed__() method or supports the sequence protocol (the __len__() method and the __getitem__() method with integer arguments starting at 0). Your point about the sorted()'s behavior seems like a fair one, though. Perhaps it does make sense to support implicit conversion to lists for generator objects passed to reversed(). -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18826 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18416] Move to absolute file paths for module.__file__
Madison May added the comment: Here's a minor revision to that patch removing an unnecessary @skip_if_dont_write_bytecode decorator from the test I added to test_import.py. No docs changes are included in the current patch -- I'm guessing this should probably wait until we have all the other details ironed out. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18416] Move to absolute file paths for module.__file__
Changes by Madison May madison@students.olin.edu: Added file: http://bugs.python.org/file31248/Issue18416_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18700] test_cgi raises ResourceWarning
Madison May added the comment: Good catch, Vajrasky. I'll close the issue and add my brief report to bug #18394. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18700 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18394] cgi.FieldStorage triggers ResourceWarning sometimes
Madison May added the comment: I ran into a similar issue (see #18700) with test_cgi. ``/home/mmay/cpython/Lib/test/test_cgi.py:276: ResourceWarning: unclosed file _io.BufferedRandom name=3`` -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18707] the readme should also talk about how to build doc.
Madison May added the comment: Here's a patch that adds a short sentence to the README's `Documentation` section that refers readers to the Doc/README.txt file. -- nosy: +madison.may Added file: http://bugs.python.org/file31267/README_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18707] the readme should also talk about how to build doc.
Madison May added the comment: Good point, Éric. It refers readers to the bug tracker, the Sphinx bug tracker, and d...@python.org in the `Contributing` section, but a link to the devguide would probably be more useful. I've tweaked the patch a bit to reflect this. -- Added file: http://bugs.python.org/file31268/README_v3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18707] the readme should also talk about how to build doc.
Madison May added the comment: Or perhaps with an alternate wording: README_v4.diff -- Added file: http://bugs.python.org/file31269/README_v4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18416] Move to absolute file paths for module.__file__
Madison May added the comment: I'm currently leaning towards having sys.path_importer_cache store the actual directory name. Exactly what I meant by Creating a new entry in sys.path_importer_cache after changing directories and importing a new module, but expressed much more succinctly :) Good to see we're on pretty much the same page. Here's a (very) preliminary patch for the issue that stores the directory name as a key in sys.path_importer_cache and ensures module.__file__ is an absolute path. I've also modified test_path_importer_cache_empty_string in test_importlib/import_/test_path.py to use os.getcwd() instead of os.curdir as the key for sys.path_importer_cache. Finally, I've added a test to test_import.py that tests that module.__file__ is equivalent to os.path.abspath(module.__file__). Look it over when you get a chance and let me know what you would change. Thanks... -- keywords: +patch Added file: http://bugs.python.org/file31236/Issue18416.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18416] Move to absolute file paths for module.__file__
Madison May added the comment:
I quickly ran the tests with each of the above edits to see what bits of the
test suite would break.
With option 1 (edits to PathFinder only):
``1 test failed:
test_importlib``
With option 2 (edits to FileFinder only):
``3 tests failed:
test_import test_importlib test_support``
With option 3 (edits to PathFinder and FileFinder):
``3 tests failed:
test_import test_importlib test_support``
So using the cwd as a key in sys.path_importer_cache seems to break fewer tests
than using '' as a key does. Perhaps that counts for something.
In test_importlib, the only test to fail was
`test_path_importer_cache_empty_string()`, for rather obvious reasons.
I haven't spent much time looking at failing tests in test_import and
test_support yet, though.
In regard to sys.path_importer_cache behavior -- at first glance, I'd lean
toward either:
1) Creating a new entry in sys.path_importer_cache after changing directories
and importing a new module (as is the case in option 1).
Key: os.getcwd() = Value: FileFinder(os.getcwd())
2) Keeping the current behavior in sys.path_importer_cache and somehow changing
the __file__ attribute a bit further down the line (perhaps in
`FileFinder._init_file_attr()` or `FileLoader.get_filename()`).
Key: '.' = Value: FileFinder('.')
or with a minor tweak for consistency with sys.path:
Key: '' = Value: FileFinder('.')
Have you given the issue any more thought, Brett?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18416
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18700] test_cgi raises ResourceWarning
New submission from Madison May: I'm currently running the tests on a 64-bit Ubuntu 13.04 laptop using the default branch of python. ``/home/mmay/cpython/Lib/test/test_cgi.py:276: ResourceWarning: unclosed file _io.BufferedRandom name=3`` -- components: Tests messages: 194782 nosy: madison.may priority: normal severity: normal status: open title: test_cgi raises ResourceWarning versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18700 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18416] Move to absolute file paths for module.__file__
Madison May added the comment: Nick, it was definitely a good thing to mention. I had to learn the edit, build, test cycle the hard way my first time. It took me a good 15-20 minutes to figure out why none of my edits seemed to change anything :) Anyhow, here's how I see the issue. It seems like we have three main options: In option one, we only modify PathFinder._path_importer_cache(). if path == '': -path = '.' +path = _os.getcwd() This associates the cwd with FileFinder(cwd) in sys.path_importer_cache In option two, we only modify FileFinder.__init__(). -self.path = path or '.' +if not path or path == '.': +path = _os.getcwd() +self.path = path This associates '.' with FileFinder(cwd) in sys.path_importer_cache. In option three, we modify both PathFinder and FileFinder. In PathFinder._path_importer_cache() we remove the line that reassigns path to '.' if path is the empty string. -if path == '': -path = '.' In FileFinder.__init__(), we set path to _os.getcwd() if path is false. -self.path = path or '.' +self.path = path or _os.getcwd() This associates the empty string with FileFinder(cwd) in sys.path_importer_cache. What are your thoughts? Which solution would you all support? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18416] Move to absolute file paths for module.__file__
Madison May added the comment: A few days ago I tried the change: ``self.path = path or _os.cwd()``, but the problem didn't seem to resolve itself. ``./python -c import blah; print(blah.__file__)`` still returned a relative path on my system. The tie between FileFinder and the __file__ attribute isn't yet obvious to me. I'm traveling for the next few days but I'll probably give it a second look when I get some free time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18416] Move to absolute file paths for module.__file__
Madison May added the comment: Thanks for the heads up, Nick. I've worked with _bootstrap.py before, so I'm familiar with the cycle. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18656] setting function.__name__ doesn't affect repr()
Madison May added the comment:
Yup, here are the relevant lines of the diff for PEP 3155:
@@ -568,7 +607,7 @@
func_repr(PyFunctionObject *op)
{
return PyUnicode_FromFormat(function %U at %p,
- op-func_name, op);
+ op-func_qualname, op);
}
--
nosy: +madison.may
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18656
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18657] Remove duplicate ACKS entries
New submission from Madison May: The title says it all. I used collections.Counter to check for duplicates in ACKS and cleaned up a few double entries. -- assignee: docs@python components: Documentation messages: 194410 nosy: docs@python, madison.may priority: normal severity: normal status: open title: Remove duplicate ACKS entries versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18657 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18657] Remove duplicate ACKS entries
Madison May added the comment: Now with 100% more patch. Thanks for the catch, David. -- keywords: +patch Added file: http://bugs.python.org/file31157/ACKS_duplicates.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18657 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18629] future division breaks timedelta division by integer
Madison May added the comment: I agree -- it's not at all intuitive that the floor division returns a decimal number of seconds, while float division raises an error. This should probably be cleaned up. In python 3.4, both float division and integer division return decimal numbers of seconds -- that's not all that intuitive, either. Python 3.4.0a0 (default:d5536c06a082+, Jul 11 2013, 20:23:54) [GCC 4.8.1] on linux Type help, copyright, credits or license for more information. from datetime import timedelta print(timedelta(seconds=3)/2) 0:00:01.50 print(timedelta(seconds=3)//2) 0:00:01.50 -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Madison May added the comment: This issue may have been dead for 3+ years, but perhaps it's time its brought back to the surface. Aside from simple being convenient for general security practices, a stdlib module for crypto routines would enable python to handle encrypted zipfiles and resolve issues like issue9170. Currently, only hashlib and hmac are available to users (see http://docs.python.org/3/library/crypto.html). I'd imagine that collaboration with the likes of Dwayne from PyCrypto or further collaboration with Geremy from Evpy would be possible, and perhaps the stdlib could build on a 3rd party crypto library. Is anyone else interested in working to make this happen (or does anyone have a good argument against a stdlib crypto library)? I imagine it would be difficult to maintain, but perhaps its at least worth giving this issue a second chance. -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Madison May added the comment: Yeah, that definitely qualifies as a good argument. I didn't consider the legal issues that would create. Let's let this issue rest in peace, then. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18416] Move to absolute file paths for module.__file__
Madison May added the comment: PathFinder or FileFinder? Changing PathFinder._path_importer_cache(cls, path) seems to fix the issue. See line 1302 in _bootstrap.py. if path == '': -path = '.' +path = _os.getcwd() $ touch blah.py; ./python -c import blah; print(blah.__file__) /home/mmay/cpython/blah.py -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18415] Normalize single/double quote usage in importlib
Madison May added the comment: No problem, Brett. Glad to hear you could get rid of those few last pesky double quotes. I'm partial to the single quotes as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18415 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18389] document that os.path.relpath does not interrogate the file system
Madison May added the comment: Thanks, David. I like your changes -- sounds a lot cleaner and more explicit. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18389] document that os.path.relpath does not interrogate the file system
Madison May added the comment: Patch for 3.4 added. I tried to keep things short and sweet. -- Added file: http://bugs.python.org/file30892/Issue18389_3-4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18415] Normalize single/double quote usage in importlib
Madison May added the comment: Patch using all single quotes for string literals, except for 3 cases of double quoted strings that contain single quotes (I thought it was probably preferable to escaping the single quotes). -- keywords: +patch nosy: +madison.may Added file: http://bugs.python.org/file30893/all_single_quotes.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18415 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18415] Normalize single/double quote usage in importlib
Madison May added the comment: Patch using all double quotes. Take your pick :) -- Added file: http://bugs.python.org/file30894/all_double_quotes.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18415 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18430] gzip, bz2, lzma: peek advances file position of existing file object
Madison May added the comment: Why would something like the following work? #At the beginning of peek() #keep track of prior offset position = self.fileobj.tell() #immediately before return statement #restore previous fileobj offset self.fileobj.seek(position) -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18430 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18430] gzip, bz2, lzma: peek advances file position of existing file object
Madison May added the comment: *wouldn't -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18430 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18430] gzip, bz2, lzma: peek advances file position of existing file object
Madison May added the comment: Sounds good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18430 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18403] Minor bug in The Python Tutorial
Madison May added the comment: Nope, definitely an error! Good catch, Xue. -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18403 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18351] Incorrect variable name in importlib._bootstrap._get_sourcefile
Madison May added the comment: I can imagine that would be incredibly frustrating -- it would drive me up the wall as well. Anyhow, glad to hear things looked good. I really appreciate your help guiding me through this one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18389] os.path.relpath gives incorrect results if start parameters is not a directory
Madison May added the comment: So the problem arises because a path to a file (not a path to a directory) is passed as an argument to start. So the way I see it, we could go one of several directions: 1) We could check for the presence of an extension in the start argument, and truncate start_path to start_path[:-1] if an extension is found. This wouldn't deal with the case where a path to a file without an extension is passed to relpath(), but it would deal with the large majority of cases. I'm in favor of this option. 2) We could add a warning to the docs and let users know that paths to files shouldn't be passed as the 'start' argument to relpath() -- only paths to directories are valid. You could perhaps even raise an error when a path to a file with an extension is passed as the 'start' argument. I've attached a patch for posixpath.py and ntpath.py with the first option in mind. The patch also contains an test case for this behavior. -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18389] os.path.relpath gives incorrect results if start parameters is not a directory
Madison May added the comment: Whoops -- I forgot to actually upload the patch. Here it is. -- keywords: +patch Added file: http://bugs.python.org/file30833/relpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18389] os.path.relpath gives incorrect results if start parameters is not a directory
Madison May added the comment: That could definitely be beneficial. I've attached a second patch with that suggestion in mind. However, note that test_unittest is failing after adding the isfile(start) check. I think its related to the large amount of mocking that's happening in test_unittest: os.path.isfile has been reassigned in each test case that fails. I haven't managed to wrap my head around it yet, but feel free to test it out for yourself. -- Added file: http://bugs.python.org/file30835/relpath_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18351] Incorrect variable name in importlib._bootstrap._get_sourcefile
Madison May added the comment: I'd be glad to -- I'll get right to work =). On a related note, rpartition is also misspelled in _get_sourcefile() on line 446. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18351] Incorrect variable name in importlib._bootstrap._get_sourcefile
Madison May added the comment: You might have to bear with me -- I'm a bit new to this. What's the protocol for functions like _get_sourcepath() that require support files for testing? I'll should probably have a couple .pyc's, .pyo's and .py files to use for testing purposes. Additionally, would you recommend writing tests for _get_sourcepath() in test_imp.py, or would another location prove better in your opinion? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18351] Incorrect variable name in importlib._bootstrap._get_sourcefile
Madison May added the comment: Yet another _get_sourcefile() related bug to report. Line 453 should be: source_path = bytcode_path[:-1] instead of source_path = bytcode_path[-1:] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18351] Incorrect variable name in importlib._bootstrap._get_sourcefile
Madison May added the comment: Here's a preliminary attempt at a patch and a small set of test cases for _get_sourcefile. I fixed one more spelling error in _get_sourcefile (bytcode - bytecode) and tweaked a bit of logic. Instead of: extension.lower()[-3:-1] != '.py' I think we needed extension.lower()[-3:-1] != 'py' You must have been having a rough day, Brett =). Anyhow, when you get a chance, take a look at this first attempt and let me know what you'd do differently. Thanks, Madison -- Added file: http://bugs.python.org/file30786/Issue18351_Python3-3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18021] Update broken link to Apple Publication Style Guide
Madison May added the comment: If the general consensus is that the APSG link should be removed, here's one more patch for you. -- Added file: http://bugs.python.org/file30775/apsg_removed.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18351] Incorrect variable name in importlib._bootstrap._get_sourcefile
Madison May added the comment: Here's a 5 character patch for the sake of completeness. -- keywords: +patch nosy: +madison.may Added file: http://bugs.python.org/file30776/Issue18351.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18351 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18352] collections.Counter with added attributes are not deepcopied properly.
Changes by Madison May madison@students.olin.edu: -- nosy: +madison.may ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18352 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18140] urlparse.urlsplit confused to fragment when password include #
Madison May added the comment: Here's a potential patch for the issue, should we decide it's worth fixing. All current tests pass with the update version of _splitnetloc(), and I've added a test to test_urlparse to check that urls with '#' or '?' in the password field are treated properly. -- keywords: +patch Added file: http://bugs.python.org/file30652/password_delimiters.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18140 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18140] urlparse.urlsplit confused to fragment when password include #
Madison May added the comment:
urllib.parse.urlsplit() in Python3.3 behaves the same way. Since urlsplit
takes an optional param allow_fragments, I don't think it should be a high
priority issue.
The relevant code from Python3.3 is below, however:
if allow_fragments and '#' in url:
url, fragment = url.split('#', 1)
if '?' in url:
url, query = url.split('?', 1)
Note that passwords containing '?' would produce a similar result, which is
perhaps mildly more concerning, as there is no flag to ignore the query portion
of the url.
That being said, I'm against making any changes to urlsplit at this point,
since that would also require modifying urlunsplit and may in fact make it much
more difficult (or impossible) to rejoin a url. The strength of the very
simple implementation we have currently is that it's always reversible.
--
nosy: +madison.may
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18140
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18140] urlparse.urlsplit confused to fragment when password include #
Madison May added the comment: My apologies -- that was an oversight on my part. Now that I look at the issue again, it's plain that it most likely won't be an issue. Problems only arise when you allow '#' to occur before '?' and then treat portion of the url between the '#' and '?' as a fragment. In this scenario, when the url is rejoined, the order of the fragment and query is switched by urlunsplit(). However, since the portion of the url with a hashtag would be treated as a the netloc, this isn't any cause for concern. We only need to ensure that the order of the components is maintained. Thanks for the heads up, Dmi. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18140 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18021] Update broken link to Apple Publication Style Guide
Madison May added the comment: So I've done a quick comparison of the two, and for the most part each entry is an identical copy of the 2009 version. Some dated entries have been removed, which I would consider a plus -- who realistically needs to know how to refer to a 56K modems these day, anyhow :) Aside from this kind of removal, a slightly modified layout, and a few updated images, I haven't noticed any significant differences. What caught your eye, Ned? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18021] Update broken link to Apple Publication Style Guide
Madison May added the comment: The attached patch updates the urls on the Documenting and Doc Quality pages to reference the new Apple Style Guide. -- keywords: +patch Added file: http://bugs.python.org/file30456/apple_style_guide.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18021] Update broken link to Apple Publication Style Guide
Madison May added the comment: Updated patch to link instead to http://help.apple.com/asg/mac. Thanks for that catch, Dmi and Terry. I have to agree that its a much better alternative. -- Added file: http://bugs.python.org/file30457/apple_style_guide_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18021] Update broken link to Apple Publication Style Guide
Madison May added the comment: I actually had a bit of a hard time even locating a copy of the 2009 version. Thanks to the Wayback Machine, here's the 2009 version of the pdf for reference: http://web.archive.org/web/20121221004340/https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/APStyleGuide/APSG_2009.pdf -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18021] Update broken link to Apple Publication Style Guide
New submission from Madison May: The links at http://docs.python.org/devguide/documenting.html#building-doc and http://docs.python.org/devguide/docquality.html to http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/APStyleGuide/APSG_2009.pdf lead to a Page Not Found message and a redirect to http://developer.apple.com/library/mac/navigation/. This url should be updated to point to another copy of the 2009 style guide or https://help.apple.com/asg/mac/2013/ASG_2013.pdf, the 2013 version of Apple's Style Guide. -- components: Devguide messages: 189659 nosy: Madison.May, ezio.melotti priority: normal severity: normal status: open title: Update broken link to Apple Publication Style Guide type: enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18021] Update broken link to Apple Publication Style Guide
Changes by Madison May madison@students.olin.edu: -- type: enhancement - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18021 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A difficulty with lists
On Wednesday, August 15, 2012 8:21:22 PM UTC-4, Terry Reedy wrote: On 8/15/2012 5:58 PM, Rob Day wrote: Yeah, my apologies for any confusion I created. Although I suppose my explanation would be somewhat true for immutable objects since they can't be modified in-place (any modification at all would cause the creation of a new immutable object right?), I now understand that it is completely and totally wrong for mutable objects. Thanks for the in-depth explanations, Terry and Rob. I feel like I have a much more solid grasp of what's going on behind the scenes after your analysis. Madison May wrote: The list nlist inside of function xx is not the same as the variable u outside of the function: nlist and u refer to two separate list objects. When you modify nlist, you are not modifying u. http://mail.python.org/mailman/listinfo/python-list This is confused and wrong. The parameter *name* 'nlist' of function xx is not the same as the *name* 'u' outside the function. The call xx(u) binds nlist to the same object that u is bound to. At that point, the two name *are* bound to the same list object. The statement nlist+=[999] dodifying nlist *does* modify u. The subsequent assignment statement nlist=nlist[:-1] rebinds 'nlist' to a *new* list object. That new object gets deleted when the function returns. So the rebinding is completely useless. This sequence, modifying the input argument and then rebinding to a new object, is bad code. Well - that's not quite true. Before calling the function, u is [1, 2, 3, 4] - but after calling the function, u is [1, 2, 3, 4, 999]. This is a result of using 'nlist += [999]' - the same thing doesn't happen if you use 'nlist = nlist+[999]' instead. I'm not completely aware of what's going on behind the scenes here, but you got it right. I think the problem is that 'nlist' is actually a reference to a list object - it points to the same place as u. Calling a python function binds parameter names to argument objects or (for *args and **kwds parameters) a collection based on argument objects. When you assign to it within the function, then it becomes separate from u - which is why nlist = nlist+[999] and nlist = nlist[:-1] don't modify u - but if you modify nlist in place before doing that, such as by using +=, then it's still pointing to u, and so u gets modified as well. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Top-posting c. (was Re: [ANNC] pybotwar-0.8)
And FWIW, I add my voice to those who prefer to read replies underneath the original text. Even if Mark were the only person vocal enough to complain, you can still rest assured that there are many more who agree. You've now heard from quite a few regular posters; there are probably several *hundred* lurkers who feel the same way, but do not post (possibly because they cannot). Also, these mails get archived all over the internet, so a generation not yet born can read and be either enlightened or irritated, as the case may be. ChrisA As a lurker, I agree completely with Chris's sentiments. -- http://mail.python.org/mailman/listinfo/python-list
Re: A difficulty with lists
On Monday, August 6, 2012 3:50:13 PM UTC-4, Mok-Kong Shen wrote: I ran the following code: def xx(nlist): print(begin: ,nlist) nlist+=[999] print(middle:,nlist) nlist=nlist[:-1] print(final: ,nlist) u=[1,2,3,4] print(u) xx(u) print(u) and obtained the following result: [1, 2, 3, 4] begin: [1, 2, 3, 4] middle: [1, 2, 3, 4, 999] final: [1, 2, 3, 4] [1, 2, 3, 4, 999] As beginner I couldn't understand why the last line wasn't [1, 2, 3, 4]. Could someone kindly help? M. K. Shen The list nlist inside of function xx is not the same as the variable u outside of the function: nlist and u refer to two separate list objects. When you modify nlist, you are not modifying u. If you wanted the last line to be [1, 2, 3, 4], you could use the code below: #BEGIN CODE def xx(nlist): print(begin: ,nlist) nlist+=[999] print(middle:,nlist) nlist=nlist[:-1] print(final: ,nlist) return nlist u=[1,2,3,4] print(u) u = xx(u) print(u) #END CODE Notice that I changed two things. First, the function xx(nlist) returns nlist. Secondly, u is reassigned to the result of xx(nlist). -- http://mail.python.org/mailman/listinfo/python-list
Re: A difficulty with lists
On Monday, August 6, 2012 3:50:13 PM UTC-4, Mok-Kong Shen wrote: I ran the following code: def xx(nlist): print(begin: ,nlist) nlist+=[999] print(middle:,nlist) nlist=nlist[:-1] print(final: ,nlist) u=[1,2,3,4] print(u) xx(u) print(u) and obtained the following result: [1, 2, 3, 4] begin: [1, 2, 3, 4] middle: [1, 2, 3, 4, 999] final: [1, 2, 3, 4] [1, 2, 3, 4, 999] As beginner I couldn't understand why the last line wasn't [1, 2, 3, 4]. Could someone kindly help? M. K. Shen I've modified your code slightly so you can see what's happening with u in the middle of function xx. Take a look: u=[1,2,3,4] def xx(nlist): print(xx(u)\n) print(At first, u and nlist refer to the same list) print(nlist: %s u: %s\n % (nlist, u)) nlist+=[999] print(nlist+=[999]\n) print(The list has been modified in place. u and nlist are still equal) print(nlist: %s u: %s\n %(nlist, u)) nlist=nlist[:-1] print(nlist=nlist[:1]\n) print(Now nlist refers to a new list object in memory that was created by) print(taking a slice of u. u and nlist are no longer equal.) print(nlist: %s u: %s %(nlist, u)) xx(u) Here's the output: xx(u) At first, u and nlist refer to the same list nlist: [1, 2, 3, 4] u: [1, 2, 3, 4] nlist+=[999] The list has been modified in place. u and nlist are still equal nlist: [1, 2, 3, 4, 999] u: [1, 2, 3, 4, 999] nlist=nlist[:1] Now nlist refers to a new list object in memory that was created by taking a slice of u. u and nlist are no longer equal. nlist: [1, 2, 3, 4] u: [1, 2, 3, 4, 999] Thank you, Rob Day, for explaining a some of what's happening behind the scenes. -- http://mail.python.org/mailman/listinfo/python-list
