[issue42193] Improve socket.bind error message
Change by flying sheep : -- components: +IO versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue42193> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42193] Improve socket.bind error message
New submission from flying sheep : In the end of my stack trace, I just see File "...", line 174, in bind_sockets sock.bind(sockaddr) OSError: [Errno 99] Cannot assign requested address It would be useful if it would tell me which socket that was in the error message. -- messages: 379865 nosy: flying sheep priority: normal severity: normal status: open title: Improve socket.bind error message ___ Python tracker <https://bugs.python.org/issue42193> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio
flying sheep added the comment: There’s this monkeypatching solution: https://pypi.org/project/nest-asyncio/ But yes, it’s a very practical problem that you can’t call async code from sync code that’s being called from async code. -- nosy: +flying sheep ___ Python tracker <https://bugs.python.org/issue33523> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37173] inspect.getfile error names module instead of passed class
Change by flying sheep : -- keywords: +patch pull_requests: +13736 stage: -> patch review pull_request: https://github.com/python/cpython/pull/13861 ___ Python tracker <https://bugs.python.org/issue37173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37173] inspect.getfile error names module instead of passed class
New submission from flying sheep : Currently, inspect.getfile(str) will report nonsense: >>> inspect.getfile(str) TypeError: is a built-in class -- components: Library (Lib) messages: 344799 nosy: flying sheep priority: normal severity: normal status: open title: inspect.getfile error names module instead of passed class versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31292] `python setup.py check --restructuredtext` fails when a include directive is present.
Change by flying sheep : -- keywords: +patch pull_requests: +9848 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31292] `python setup.py check --restructuredtext` fails when a include directive is present.
Changes by flying sheep <flying-sh...@web.de>: -- pull_requests: +3293 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31292] `python setup.py check --restructuredtext` fails when a include directive is present.
flying sheep added the comment: I should have linked the file: distutils/command/check.py -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31292] `python setup.py check --restructuredtext` fails when a include directive is present.
New submission from flying sheep: If I have a setup.py containing a include directive, and use the command in the title, I get Traceback (most recent call last): [...] File "/usr/lib/python3.6/site-packages/docutils/parsers/rst/directives/misc.py", line 59, in run source_dir = os.path.dirname(os.path.abspath(source)) File "/usr/lib/python3.6/posixpath.py", line 369, in abspath path = os.fspath(path) TypeError: expected str, bytes or os.PathLike object, not _io.StringIO The bug is in this method: distutils.command.check.check._check_rst_data The first line already hints at it: `source_path = StringIO()` StringIO instances aren’t paths, but at least the include directive (docutils.parsers.rst.directives.misc.Include) expects one. -- components: Distutils files: check-test.py messages: 300953 nosy: dstufft, flying sheep, merwok priority: normal severity: normal status: open title: `python setup.py check --restructuredtext` fails when a include directive is present. type: crash versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file47104/check-test.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10436] tarfile.extractfile in "r|" stream mode fails with filenames or members from getmembers()
flying sheep added the comment: well, we should just allow extractall(members=['foo', 'bar']) currently members only accepts TarInfo objects, not filenames, but it’s easy to accept both. https://github.com/python/cpython/blob/74683fc6247c522ae955a6e7308b8ff51def35d8/Lib/tarfile.py#L1991-L1999 sth like: filenames = set() for member in members: if isinstance(member, TarInfo): # do what’s done now else: filenames.add(member) for tarinfo in self: if tarinfo.name in filenames: self.extract(tarinfo) -- nosy: +flying sheep ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10436> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29262] Provide a way to check for *real* typing.Union instances
flying sheep added the comment: Cool! This set of basic initial check will consist of all the is_* functions that were mentioned right? FWIW I also think that this is the way to go, as it’s not obvious if the semantics should be “conforms to this type annotation” or “is a type annotation of that kind” or other variants. In case this isn’t already too much future think: What should be the way forward from there? E.g. when working with Union[A, B], you will probably want to get “(A, B)”. So will that mean more introspection functions (like union_types(Union[str,int]), or public APIs for typings (e.g. a_union.__iter__() or a_union.types)? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29262] Provide a way to check for *real* typing.Union instances
New submission from flying sheep: typing.Union prevents the use of `isinstance` and `issubclass` via a hook. This is presumably to prevent errors that would arise if someone tried to do issubclass(A, Union[A, B]) or isinstance(A(), Union[A, B]), because Union isn’t specified in the PEP to allow a check like this, and doesn’t implement it. (Instead it throws said error) However, as far as I can see there is no blessed way to check if an object was returned by Union.__getitem__(). A simple way that works is: sig = inspect.signature(f) ann = sig.parameters['arg1'].annotation is_an_union = isinstance(ann, typing._Union) but _Union is a private class, and an implementation detail. is there a blessed way to do this? If not, one should be added. -- components: Library (Lib) messages: 285410 nosy: flying sheep priority: normal severity: normal status: open title: Provide a way to check for *real* typing.Union instances versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27948] f-strings: allow backslashes only in the string parts, not in the expression parts
Changes by flying sheep <flying-sh...@web.de>: -- nosy: +flying sheep ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26713] Change f-literal grammar so that escaping isn’t possible or necessary
Changes by flying sheep <flying-sh...@web.de>: -- type: -> behavior versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26713] Change f-literal grammar so that escaping isn’t possible or necessary
New submission from flying sheep:
code inside of the braces of an f-literal should have the exact same lexing
rules than outside *except* for an otherwise unparsable !, :, or } signifying
the end of the replacement field
1. every other language with template literals has it that way
2. it makes sense that the content of the f-literal is a “hole” in which normal
code goes until a !, : or } signifies its end
3. escaping code that will be evaluated reeks of “eval” even though it isn’t
as it is now, it’s very confusing as the contents are neither code nor string
content.
that might be one reason why many people get it wrong and think it can be
stored unevaluatedly and thus provides a security risk (which is obv. wrong)
the whole section after “A consequence of sharing the same syntax as regular
string literals is…” has to be removed and made unnecessary by allowing
everything otherwise legal inside.
e.g. f'spam{(lambda: 1)():<4}' would be legal and be exactly the same as
'{:<4}'.format((lambda: 1)())
--
messages: 263026
nosy: flying sheep
priority: normal
severity: normal
status: open
title: Change f-literal grammar so that escaping isn’t possible or necessary
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26713>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26277] Allow zipapp to target modules
New submission from flying sheep:
currently, zipapp’s notion of __main__.py is very different from the usual.
the root directory of a zipapp is not a module, therefore __init__.py isn’t
used and relative imports from __main__.py don’t work.
i propose that the zipapp functionality is amended/changed to
1. allow more than one target directory (bundle multiple modules)
2. allow creation of a __main__.py that contains a runpy-powered module runner
so maybe we could specify the module itself as entry point to get this behavior
zipapp -m my_module dependency.py my_module
should create
my_module.pyz
├ __main__.py → ...runpy.run_module('my_module')
├ dependency.py
└ my_module
├ __init__.py
└ __main__.py → from . import ...
or there would be another option to specify it.
--
components: Extension Modules
messages: 259476
nosy: flying sheep
priority: normal
severity: normal
status: open
title: Allow zipapp to target modules
type: enhancement
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26277>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25830] _TypeAlias: Discrepancy between docstring and behavior
New submission from flying sheep: _TypeAlias claims in its docstring that “It can be used in instance and subclass checks”, yet promptly contradicts itself if you try it: “Type aliases cannot be used with isinstance().” it would be useful to either document (and therefore bless) type_impl, or make it actually work with isinstance (probably by delegating to type_impl) -- components: Library (Lib) messages: 256154 nosy: flying sheep priority: normal severity: normal status: open title: _TypeAlias: Discrepancy between docstring and behavior type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7175] Define a standard location and API for configuration files
flying sheep added the comment:
just because people do something doesn’t mean it’s right.
i guess the tendency for CLI applications to do it wrong comes from
1. their ad-hoc beginnings. you usually start with one script file and extend it
2. availability expanduser('~') is in the stdlib and more well-known than e.g.
appdirs, and people don’t like to add dependencies to small things
3. the shell and old, widely used applications using ~/.appname, so it’s more
well-know to do that
on the other hand, GUI applications usually have a build system in place for UI
file compilation, need a .desktop file installed, and so on, i.e. need more
boilerplate and dependencies from the start, and people have to research how to
do things properly. GUI libraries have their built-in standard dirs interfaces
as well.
another thing. on the python-ideas thread someone mentioned that
> I count 17 of those on my Windows machine (!) right now, including .idlerc,
> .ipython, .matplotlib, .ipylint.d etc.
this is horrible! this is so obviously the wrong thing to do. i hope having the
module will reduce the number of similar atrocities.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7175>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7175] Define a standard location and API for configuration files
flying sheep added the comment: you’re right about the two problems being mixed, however not about the standards. also you’re intermingling conventions with actual standards. the directory standards for all three big OSs are either not going to change or fitted with a backwards-compatibility layer (like windows did with the “My Music/Videos/*” folders): https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/MacOSXDirectories/MacOSXDirectories.html http://windows.microsoft.com/de-de/windows-8/what-appdata-folder https://msdn.microsoft.com/en-us/library/windows/desktop/dd378457%28v=vs.85%29.aspx http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html all three OSs have stable, widely followed standards in place, and the idea of providing a python stdlib API for them received an almost unanimously positive response – with the sole exception being you. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7175] Define a standard location and API for configuration files
flying sheep added the comment:
of course if there is a chance that some specific config file exists at a known
location, it’s the only sane choice to try and look for it there iff it isn’t
in its preferred location.
e.g. fontconfig made that switch some time ago: it used to be ~/.fonts.conf,
now it’s ${XDG_CONFIG_HOME-$HOME/.config}/fontconfig/fonts.conf
the library will look at the new position and if it can’t find anything there,
it looks at the old one.
but for new config files we should follow standards. on windows and OSX there
are different ones: see the current discussion on python-ideas for specifics
and problems. but on linux the only standard for this which i know is
XDG-base-directories, so we should follow that for new config files.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7175>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7175] Define a standard location and API for configuration files
flying sheep added the comment: hi mark, i’ve just lengthily replied to you on python-ideas. in short: nope! many command line tools that are relatively new (among them your examples git and pip) honor the specs, my ~/.cache, ~/.config, and ~/.local/share is full of things belonging to libraries, cli tools, my DE, and of course also GUI applications. please let’s continue this discussion on python-ideas if you’re still not convinced ☺ -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7175] Define a standard location and API for configuration files
flying sheep added the comment: no, sorry, but ~/.python is wrong on linux. there exists a standard about where things belong: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html it says that configuration stuff belongs into `XDG_CONFIG_HOME`, with a fallback to `~/.config/` i propose to add the `appdirs` module to the stdlib so that programs finally don’t have to guess and hack around this kind of things. https://pypi.python.org/pypi/appdirs -- nosy: +flying sheep ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24849] Add __len__ to map, everything in itertools
flying sheep added the comment: The *iterable* itself may be reentrant, but the iterator formed from iter(iterable) is not. So by your previous comment, giving the iterator form a length is not appropriate. With the exception of tee, all the functions in itertools return iterators. ah, so your gripe is that the itertools functions return iterators, not (possibly) reentrant objects like range(). and changing that would break backwards compatibility, since the documentation says “iterator”, not “iterable” (i.e. people can expect e.g. next(groupby(...))) to work. that’s probably the end of this :( the only thing i can imagine that adds reentrant properties (and an useful len()) to iterators would be an optional function (maybe __uniter__ :D) that returns an iterable whose __iter__ function creates a restarted iterator copy, or an optional function that directly returns such a copy. probably too much to ask for :/ Since you can't rely on it having a length, you have to program as if it doesn't. So in practice, I believe this will just add complication. I don’t agree here. If something accepts iterables and expects to sometimes be called on iterators and sometimes on sequences/len()gthy objects, it will already try/catch len(iterable) and do something useful if that succeeds. The best we ended-up with has having __length_hint__ to indicate size to list(). Just out of interest, how does my __uniter__ compare? because it changed their boolean value from always-true it does? is it forbidden to define methods so that int(bool(o)) != len(o)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24849] Add __len__ to map, everything in itertools
flying sheep added the comment: Hi, and sorry David, but I think you haven’t understood what I was proposing. Maybe that was too much text and detail to read at once, while skipping the relevant details: Python has iterators and iterables. iterators are non-reentrant iterables: once they are exhausted, they are useless. But there are also iterables that create new, iterators whenever iter(iterable) is called (e.g. implicitly in a for loop). They are reentrant. This is why you can loop sequences such as lists more than once. ——— One of those reentrant iterables is range(), whose __iter__ functions creates new lazy iterables, which has a __len__, and so on. It even has random access just like a sequence. Now it’s always entirely possible to *lazily* determine len(chain(range(200), [1,2,5])), which is of course len(range(200)) + len([1,2,5]) = 200 + 3 = 203. No reentrant iterables are necessary here, only iterables with a __len__. (Simply calling len() on them all is sufficient, as it could only create a TypeError which would propagate upwards) ——— To reiterate: 1. Lazy doesn’t mean non-reentrant, just like range() demonstrates. 2. I didn’t propose that this works on arbitrary iterables, only that it works if you supply iterables with suitable properties (and throws ValueError otherwise, just like len(some_generator_function()) already does) 3. I know what I’m doing, please trust me and read my proposal carefully ;) -- resolution: rejected - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24849] Add __len__ to map, everything in itertools
flying sheep added the comment: To elaborate more on my second point (“No reentrant iterables are necessary here, only iterables with a __len__”) What i meant here is that inside a call of chain(*iterables), such as chain(foo, bar, *baz_generator()), the paramter “iterables” is always a tuple, i.e. a sequence. So it is always possible to just call len() on each element of “iterables” and either get a ValueError or a collection of summable integers. With other itertools functions, we’d need to determine beforehand if we have reentrant iterables or not. This might be a problem, and for some too un-lazy (e.g. groupby) But at the very very least, we could implement this for everything where i didn’t write “(r)”: map, accumulate, chain, islice, starmap, tee, product, permutations, combinations, combinations_with_replacement -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24849] Add __len__ to map, everything in itertools
New submission from flying sheep: Things like progressbars want len() to work on iterated objects. It’s possible to define __len__ for many of the iterables returned by itertools. some arguments have to be iterated to find the len(): of course we have to check if those are reentrant, and raise a TypeError if they are non-reentrant. (signified by “(r)→”) for the predicate functions, it’s questionable if we should offer it, since they might take a long time and “len” is a property-like function that feels like it should return fast. map(func, iterable) → len(iterable) count(), cycle(), repeat() → infinty, but because len() returns integers, and there’s only float infinity, that’s impossible accumulate(iterable) → len(iterable) chain(*iterables) → sum(len(it) for it in iterables) chain.from_iterable(iterables) (r)→ like the above compress(data, selectors) (r)→ sum(1 for s in selectors if s) dropwhile(pred, iterable) (r)→ for skip, r in enumerate(map(pred, iterable)): if r: return len(iterable) - skip filterfalse(pred, iterable) (r)→ sum(1 for r in map(pred, iterable) if r) groupby(iterable[, keyfunc]) (r)→ no way but to actually execute it all islice(seq, [start,] stop [, step]) → calculatable if len(seq) is possible starmap(function, iterables) → len(iterables) takewhile(pred, iterable) (r)→ for skip, r in enumerate(map(pred, iterable)): if not r: return skip tee(iterable[, n]) → n zip_longest(*iterables[, fillvalue]) (r)→ max(len(it) for it in iterables) product(), permutations(), combinations(), combinations_with_replacement() → there’s math for that. -- components: Library (Lib) messages: 248451 nosy: flying sheep priority: normal severity: normal status: open title: Add __len__ to map, everything in itertools type: enhancement versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23275] Can assign [] = (), but not () = []
flying sheep added the comment: isn't it logical? [] is a mutable data structure while () is a immutable data structure but you don’t assign to data structures, but to names. you *modify* data structures. and in the square bracket assignment syntax you don’t modify the list created by the []. in fact the [] never even create a list. — also it’s news to me that [a, b] = range(2) works! i always did a, b = range(2), and knew that (a, b) = range(2) works. but assigning to something looking like a list literal is new and surprising to me. (and i thought i’ve mastered every corner of python’s syntax) -- nosy: +flying sheep ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23275 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18156] Add an 'attr' attribute to AttributeError
flying sheep added the comment: yeah, exactly: my idea was to add a reference to the original object (AttributeError.target). together with this bug, that would be the AttributeError part of PEP 473, which i really like! -- nosy: +flying sheep ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22716] Add reference to the object missing an attribute to AttributeError
flying sheep added the comment: sure, go ahead! i wasn’t aware of PEP nor issue, so sorry for filing a dupe. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22716 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22716] Add reference to the object missing an attribute to AttributeError
flying sheep added the comment: No, this is about the object which misses an argument, not the attribute name. But thanks for the pointer: one combined fix for both would be the smartest thing to do. -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22716 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22716] Add reference to the object missing an attribute to AttributeError
New submission from flying sheep: Trying to replicate a Ruby Gem that raises a “did you mean” error when mistyping a method name, I hit a showstopper: There seems to be no way to get the object which misses an attribute from an AttributeError. I propose the appended patch (it might be completely broken because I’m not experienced in the Python C API, but I tried) -- components: Interpreter Core files: attribute_error_origin.patch keywords: patch messages: 229923 nosy: flying sheep priority: normal severity: normal status: open title: Add reference to the object missing an attribute to AttributeError type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file37004/attribute_error_origin.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22716 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18234] Unicodedata module should provide access to codepoint aliases
flying sheep added the comment:
IDK if it came with unicode 7.0, but there is clarification:
# Note that currently the only instances of multiple aliases of the same
# type for a single code point are either of type control or abbreviation.
# An alias of type abbreviation can, in principle, be added for any code
# point, although currently aliases of type correction do not have
# any additional aliases of type abbreviation. Such relationships
# are not enforced by stability policies.
it says “currently”, so it isn’t guaranteed to stay that way, and other types
could also be specified multiple times in the future.
so as much as i’d like it if we could follow Alexander’s proposal, i think we
shouldn’t extend the function that way if it would either return a name string,
a default value, a list of aliases, or raise an exception: too complex.
i think we should create:
unicodedata.aliases(chr,
type=(None|'correction'|'control'|'alternate'|'figment'|'abbreviation'))
and make
aliases(chr) return a dict with all aliases for the character, and make
aliases(chr, type) return a list of aliases for that type (possibly empty)
examples:
aliases('\b') == {'control': ['BACKSPACE'], 'abbreviation': ['BS']}
aliases('\b', 'control') == ['BACKSPACE']
aliases('b') == {}
aliases('b', 'control') == []
---
alternative: when specifying a type, it’ll raise an error if no alias of this
type exists. but because of the sparse nature of aliases i’m against that.
--
nosy: +flying sheep
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18234
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22612] Add block info to unicodedata
New submission from flying sheep: See also #6331. The repo https://github.com/nagisa/unicodeblocks contains pretty much the functionality i’d like to see: a way to get access to information about all blocks, and a way to get the block name a char is in. I propose to include something very similar to those two APIs in unicodedata: unicodedata.Block: class with start, end, and name property. its __contains__ should work for single-char-strings (which tests if that char is in the block) and for ints (which tests if the codepoint is in the block) maybe make it iterable over its chars? unicodedata.blocks: OrderedDict of str (block name) → Block object mappings ordered by Block.start. then blocks.keys() would yield the names in order, and blocks.values() the block objects in order. unicodedata.block_of(chr, name_only=False): returns the Block object for which “chr in block” is True, or its name. --- alternative: make the Block class an unfancy namedtuple without __contains__ method. --- Together with #18234, fixing this bug will complete UnicodeData support in python, i guess. -- messages: 229101 nosy: flying sheep priority: normal severity: normal status: open title: Add block info to unicodedata type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22612 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18172] New easter egg: insecure string pickle
New submission from flying sheep: the second meaning of the error message “insecure string pickle” inspired at least two different people independently of drawing it. i’d wish for a link to one of those pics in the docstring or message of the error. picture: http://i.imgur.com/To3DQ6J.jpg thread: http://www.reddit.com/r/Python/comments/1fymy0/i_got_a_funny_error_trying_to_open_a_file_and/ we’d have to host the pic ourselves since imgur isn’t guaranteed to retain the picture (although that’d need many consecutive months of no one following the link) -- components: Library (Lib) messages: 190851 nosy: flying sheep priority: normal severity: normal status: open title: New easter egg: insecure string pickle type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18172 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17410] Generator-based HTMLParser
New submission from flying sheep: hi, i have an idea on how to make an internal change to html.parser.HTMLParser, which would expose a token generator interface. after that, we would be able to do e.g. list(HTMLParser().tokenize(data)) or even parser = HTMLParser() for chunk in pipe_in_html(): yield from parser.tokenize(chunk) --- the changes affect excluively HTMLParser’s methods and would unfortunately require a behavior change to most (internal) parse_* methods. the changes go as follows: 1. the tokenize(data=None, end=False) method is added. it contains mainly goahead’s body with an prepended snippet to append passed data to raw_data, and all handle_* calls changed to yield token, data. 2. all parse_* methods which returned an int and called one handle_* method are changed to return an (int, token) tuple (so that tokenize can yield the tokens) 3. goahead is changed to a skeleton implementation based on traversing the list created by tokenize, experiencing no changed behavior. all changes would only affect the behavior of the parse_* methods, and the addition of the tokenize method: the tokens are discarded if goahead, feed, or close are called. (this can of course be changed if advisable) --- since this is my first contribution, i’m unsure if i shall already add the patch, unknowing if the changes to the internal parse_* methods are acceptable at all. what do you say? PS: the tokens are named like the handle_* methods, and the current goahead implementation basically calls getattr(self, 'handle_' + token)(data) for each (token, data) tuple. This can be changed to a token: method dict or a classic “switch” elif stack. -- messages: 184096 nosy: flying sheep priority: normal severity: normal status: open title: Generator-based HTMLParser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17410 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17410] Generator-based HTMLParser
Changes by flying sheep flying-sh...@web.de: -- components: +XML type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17410 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17410] Generator-based HTMLParser
flying sheep added the comment: no, i didn’t change anything that didn’t have to be changed to expose the tokens. i kept the changes as minimal as possible. and the tests pass! i attached the patch. --- aside thoughts: i had to change _markupbase.py, too, but i wonder why it’s even a separate module: it is only ever imported by html.parser and its only content, ParserBase, is only subclassed once (by HTMLParser). both classes are so intertwined and dependent on each other (ParserBase calls HTMLParser methods that it itself doesn’t even define) that i think _markupbase should just be scrapped and included into HTMLParser. -- keywords: +patch Added file: http://bugs.python.org/file29401/htmltokenizer.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17410 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17410] Generator-based HTMLParser
flying sheep added the comment: whoops, left my editor modeline in. i knew that was going to happen. -- Added file: http://bugs.python.org/file29402/htmltokenizer.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17410 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17410] Generator-based HTMLParser
Changes by flying sheep flying-sh...@web.de: Removed file: http://bugs.python.org/file29401/htmltokenizer.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17410 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime cannot parse ISO 8601 dates and times
flying sheep added the comment: there is a module that parses those strings pretty nicely, it’s called pyiso8601: http://code.google.com/p/pyiso8601/ in the context of writing a better plistlib, i also needed the capability to parse those strings, and decided not to use the sucky incomplete implementation of plistlib, but the one mentioned above. i py3ified it, eliminating quite some code, and the result is pretty terse, check it out: https://github.com/flying-sheep/plist/blob/master/iso8601.py note that that implementation returns utc-datetimes for timezoneless strings, instead of naive ones. (l.30) -- nosy: +flying sheep ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
flying sheep flying-sh...@web.de added the comment: this is annoying: i’m creating a reindentation script that reindents any valid python script. the user can specify if, and how many spaces he/she wants to use per indentation level. `0` or leaving the option out means “one tab per level”. if the argument is given, appended code works as intended. but in the default case, the code fails for any of the two default values i tried. i would expect that one of the default values works: either `0`, if the default value *is* converted via the `type` function, or `\t` if the default value bypasses it. it seems that argparse applies the `type` function to the default instantly, and then to the argument (be it the already-converted default or a passed option). this breaks `type` functions which aren’t reflexive for values from their result set, i.e.: `t(x) = y = t(y) = y` must be true for all `x` that the function can handle -- nosy: +flying sheep Added file: http://bugs.python.org/file23767/argparse_test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
flying sheep flying-sh...@web.de added the comment: i don’t know, since i get python from the ubuntu repositories, sorry. in which python release will this patch first be integrated? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
