Re: [Python-Dev] Fwd: str(IntEnum)
* Demian Brecht [2015-02-20 10:24:53 -0800]:
> These and other implementations return a string representation of the
> instance’s value, not a string representation of the object itself. Whereas
> elsewhere in the standard library:
>
> >>> str(ProtocolError('url', 42, 'msg', ''))
> '’
> >>> str(URLError('reason'))
> '’
> >>> str(Cookie(0, '', '', '4', '', '', '', '', '', '', '', 0, '', '', '', ''))
> ''
>
> The specific problem that I encountered was when swapping an IntEnum
> implementation for ints in http.client, which caused a change in logging
> output (from int.__str__ to Enum.__str__), which was a bit of a surprise,
> especially given the value is a builtin type.
>
> I think that a decent rule around the usage of __str__ is that it should be a
> string representation of the value, not of the object. Failing the ability to
> logically coerce the value to a string, it should simply fall back to
> repr(obj).
>
> Of course, I realize that the chances of this change being made to such a
> fundamental (and largely inconsequential) feature are likely nil, but I
> thought I’d share my thoughts anyways.
>>> foo = object()
>>> str(foo)
''
>>> repr(foo)
''
This is exactly what you see above. ;)
Florian
--
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
I love long mails! | http://email.is-not-s.ms/
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.lstrip bug?
* lou xiao [2015-03-11 01:27:21 +0800]:
> I find a bug in str.lstrip, when i call str.lstrip, i get this result.
You're misunderstanding how str.strip works. It takes a set of
characters and removes them all from the beginning:
>>> "abababcd".lstrip('ab')
>>> 'cd'
Florian
--
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
I love long mails! | http://email.is-not-s.ms/
pgpJPx9uFbx98.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible wrong behavior of the dict?
* Zaur Shibzukhov [2015-03-17 22:29:07 +0300]: > Yes... But I expected that dict constructor will use `__getitem__` or > `items` method of MyDict instance in order to retrieve items of the MyDict > instance during construction of the dict instance... Instead it interpreted > MyDict instance as the dict instance during construction of new dict.This > exactly caused my confusion. Subclassing builtins is always a recipe for trouble, because the C implementation doesn't necessarily call your Python methods. You should probably use collections.UserDict or collections.abc.(Mutable)Mapping instead: https://docs.python.org/3/library/collections.html#collections.UserDict https://docs.python.org/3/library/collections.abc.html#collections.abc.Mapping Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgp57NLMvC4Lp.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
* Wolfgang Langner [2015-04-23 10:43:52 +0200]: > 2. Using it in the language as part of the function signature, my first > thought was oh good, then I changed my mind >to: oh it can be very ugly and unreadable, it is the wrong place. >Now I am against it, best is, if I have to specify type signatures, do > it in one place, keep them up to date. >Most of the time this is the documentation. Why not use the docstring > with a standard type specifier for this. >Suggested here: > http://pydev.blogspot.de/2015/04/type-hinting-on-python.html While I happen to agree with you (but I'm happy with both variants really), I think that's a thing which has definitely been decided already. The idea is also listed in the PEP: https://www.python.org/dev/peps/pep-0484/#other-backwards-compatible-conventions Docstrings. There is an existing convention for docstrings, based on the Sphinx notation ( :type arg1: description ). This is pretty verbose (an extra line per parameter), and not very elegant. We could also make up something new, but the annotation syntax is hard to beat (because it was designed for this very purpose). > For nearly every function I have written, there is a docstring and most of > the time also a type specified. > But if I must provide all this in a second place it is not the right way to > go. Over time normally one place misses some changes and is wrong. It seems there's an extension for Sphinx already to use type annotations: https://pypi.python.org/pypi/sphinx-autodoc-annotation It seems to be older than PEP 484 (December 2013), so I hope it'll be updated or already work well with the ideas in the PEP. > Also ask why no one used type specifier, they are possible since Python 3.0 > ? > Because it is the wrong way for Python. Well, except that Sphinx extension, and MyPy, and MicroPython, and a thing which already exists for run-time type checking[1] and probably a whole lot more. The whole *reason* for PEP 484 (at least from my perspective) is to have a common base for the existing usages of type annotations. Florian [1] https://github.com/ceronman/typeannotations -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgp0dRiwqbI7j.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's missing in PEP-484 (Type hints)
* Dima Tisnek [2015-04-30 13:41:53 +0200]: > # lambda > Not mentioned in the PEP, omitted for convenience or is there a rationale? > f = lambda x: None if x is None else str(x ** 2) > Current syntax seems to preclude annotation of `x` due to colon. > Current syntax sort of allows lamba return type annotation, but it's > easy to confuse with `f`. Not sure if you'd really want to stuff type annotations into a lambda... at that point you'd IMHO be better off by using a real function. > # local variables > Not mentioned in the PEP > Non-trivial code could really use these. > > > # global variables > Not mentioned in the PEP > Module-level globals are part of API, annotation is welcome. > What is the syntax? > > > # comprehensions > [3 * x.data for x in foo if "bar" in x.type] > Arguable, perhaps annotation is only needed on `foo` here, but then > how complex comprehensions, e.g. below, the intermediate comprehension > could use an annotation > [xx foj y in [...] if ...] > > > # class attributes > s = socket.socket(...) > s.type, s.family, s.proto # int > s.fileno # callable > If annotations are only available for methods, it will lead to > Java-style explicit getters and setters. > Python language and data model prefers properties instead, thus > annotations are needed on attributes. > > > # plain data > user1 = dict(id=123, # always int > name="uuu", # always str > ...) # other fields possible > smth = [42, "xx", ...] > (why not namedtuple? b/c extensible, mutable) > At least one PHP IDE allows to annotate PDO. > Perhaps it's just bad taste in Python? Or is there a valid use-case? Most (all?) of this is actually mentioned in the PEP: https://www.python.org/dev/peps/pep-0484/#type-comments Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpZkNAI4_hcR.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anomaly
* Mark Rosenblitt-Janssen [2015-05-10 11:34:52
-0500]:
> Here's something that might be wrong in Python (tried on v2.7):
>
> >>> class int(str): pass
>
> >>> int(3)
> '3'
What's so odd about this? "class int" is an assignment to "int", i.e.
what you're doing here is basically:
int = str
int(3) # really str(3)
* Mark Rosenblitt-Janssen [2015-05-10 19:14:18
-0500]:
> In case the example given at the start of the thread wasn't
> interesting enough, it also works in the other direction:
>
> >>> class str(int): pass
>
> >>> str('2')
> 2 #<- an integer!!!
Same thing. You're shadowing the builtin.
Florian
--
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
I love long mails! | http://email.is-not-s.ms/
pgp4DcbzxrzoZ.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 migration status update across some key subcommunities (was Re: 2.7 is here until 2020, please don't call it a waste.)
* Nick Coghlan [2015-06-01 00:15:01 +1000]: > On 31 May 2015 at 19:07, Ludovic Gasc wrote: > > About Python 3 migration, I think that one of our best control stick is > > newcomers, and by extension, Python trainers/teachers. > > If newcomers learn first Python 3, when they will start to work > > professionally, they should help to rationalize the Python 3 migration > > inside existing dev teams, especially because they don't have an interest > > conflict based on the fact that they haven't written plenty of code with > > Python 2. > > 2020 is around the corner, 5 years shouldn't be enough to change the > > community mind, I don't know. > > The education community started switching a while back - if you watch > Carrie-Anne Philbin's PyCon UK 2014 keynote, one of her requests for > the broader Python community was for everyone else to just catch up > already in order to reduce student's confusion (she phrased it more > politely than that, though). Educators need to tweak examples and > exercises to account for a version switch, but that's substantially > easier than migrating hundreds of thousands or even millions of lines > of production code. > > And yes, if you learn Python 3 first, subsequently encountering Python > 2's quirks and cruft is likely to encourage folks that know both > versions of the language to start advocating for a version upgrade :) I think a big issue here is the lack of good newcomer tutorials for Python 3. In the #python IRC channel, "learn Python the hard way"[1] is often recommended, and the common consensus seems to be that all other tutorials (other than the official one[2] which is clearly not aimed at newcomers to programming) seem to lack in some way. LPTHW is Python 2 only, so at least from what I see in #python, many newcomers are recommended to learn Python 2 rather than 3 because of that. I agree migrating large existing codebases (and developers) from 2 to 3 can be quite an issue, and a lot of energy went into making this easier (which is good!). But I also think nobody fresh to Python should start learning Python 2 now, except when there's a compelling reason (such as unported libraries without alternatives). Florian [1] http://learnpythonthehardway.org/book/ [2] https://docs.python.org/3/tutorial/index.html -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpeWqOOlFXHd.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
* Steven D'Aprano [2015-07-14 23:41:56 +1000]: > On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote: > > https://bugs.python.org/issue21238 introduces detection of > > missing/misspelt mock.assert_xxx() calls on getattr level in Python > > 3.5 > > > > Michael and Kushal are of the opinion that "assret" is a common typo > > of "assert" and should be supported in a sense that it also triggers > > AttributeError and is not silently ignored like a mocked user > > attribute. > > > > I disagree > > I must admit I don't use mock so don't quite understand what is going on > in this bug report. Without using spec/autospec, a mock (by design) supports calling any method on itself, which returns another mock: >>> m = mock.Mock() >>> m.eggs() >>> m.bacon() However, it also has some special methods to see if it has been called: >>> m.assert_called_with() [...] AssertionError: Expected call: mock() Not called Now because of that, if you do a typo, you won't notice in a test: >>> m.assert_caled_with() With the patch, an AttributeError is raised if you call something starting with assert or assret instead. Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpNFVsIA898p.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
* Ron Adam [2015-07-19 11:17:10 -0400]: > I had to look at the source to figure out what this thread was really all > about. > > Basically it looks to me the purpose of adding "assret" is to add an "alias > check" for "unsafe" methods. It doesn't actually add an "alias". It allows > a developer to use a valid alias to avoid conflicting with methods starting > with assert that will still work with the mock module. > > The mock module says that when "unsafe" flag is set to True, it will not > raise AssertionError for methods beginning with "assert" and "assret". It > doesn't specify what "unsafe" means, and why you would want to do that. > > So first do this... > > * Document "unsafe" in mock module. The issue is that Mock objects (if not using spec/autospec) allow *any* method to be called, and return another mock: >>> m = mock.Mock() >>> m.foo() But they *also* have some special methods to check if they have been called: >>> m.assert_called_with() [...] AssertionError: Expected call: mock() Not called But if you do a typo, the test silently doesn't fail (because it's returning a new mock instead of checking if it has been called): >>> m.assert_called() With the patch, everything starting with "assert" or "assret" (e.g. my example above) raises an AttributeError so these kind of issues can't happen. The thing people are discussing about is whether this should also happen if you do "m.assret_called_with()" (i.e. if this is a common enough typo to warrant a special exception), or if *only* things starting with assert_* are checked. The merged patch also treats "assret_*" as a typo, and some people think this is a wart/unnecessary/harmful and only "assert_*" should raise an AttributionError, i.e. the patch should be amended/reverted. > I presume "unsafe" in this case means the method will not fail if an > optimise flag is used because an assert in an assert method will not fail. > > The problem I see is checking for "assert" by name convention is dubious to > start with. An method that begins with assert may not actually use > "assert", and one's that don't may possibly use it. > > A better way is to have a function in the inspect module that will return > True if a function uses the "assert" keyword. > > That is trickier than it sounds, because the optimize flag causes the > asserts to be removed. So it may require setting a flag on a function if > it's source contained "assert". > > With a reliable test for "assert", the check for an naming convention alias > is not needed. > > > If I've still not quite got the gist of this issue, the please correct me. This has nothing to do with the assert *keyword* or optimization - only with the behaviour of mock and its "assert_*" methods. I hope this clears things up! Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpx7vr5AxTWJ.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
* Ron Adam [2015-07-19 18:06:22 -0400]: > > > On 07/19/2015 02:33 PM, Florian Bruhin wrote: > >* Ron Adam [2015-07-19 11:17:10 -0400]: > >>>I had to look at the source to figure out what this thread was really all > >>>about. > > And it seems I don't quite get it still, but I am trying. No worries - I'll try to clarify until things are clear :) > >>>Basically it looks to me the purpose of adding "assret" is to add an "alias > >>>check" for "unsafe" methods. It doesn't actually add an "alias". It > >>>allows > >>>a developer to use a valid alias to avoid conflicting with methods starting > >>>with assert that will still work with the mock module. > >>> > >>>The mock module says that when "unsafe" flag is set to True, it will not > >>>raise AssertionError for methods beginning with "assert" and "assret". It > >>>doesn't specify what "unsafe" means, and why you would want to do that. > >>> > >>>So first do this... > >>> > >>> * Document "unsafe" in mock module. > > I still think documenting the purpose of "unsafe", rather than just the > effect it has is important. > > From the confusion in this thread, (including my own), it's clear the > documentation does need some attention. > > > There are only two places where it mentions "unsafe" in the docs... > > The class signature... > > """ > class unittest.mock.Mock(spec=None, side_effect=None, return_value=DEFAULT, > wraps=None, name=None, spec_set=None, unsafe=False, **kwargs) > """ > > > And in the section below that. > > """ > unsafe: By default if any attribute starts with assert or assret will raise > an AttributeError. Passing unsafe=True will allow access to these > attributes. > """ > > But that doesn't explain the purpose or why these are unsafe or why it > should throw an AttributeError. Or what to do with that AttributeError. It's "unsafe" because tests which: 1) are using the assert_* methods of a mock, and 2) where the programmer did a typo (assert_called() instead of assert_called_with() for example) do silently pass. > >But if you do a typo, the test silently doesn't fail (because it's returning > >a > >new mock instead of checking if it has been called): > > Do you mean silently passes? Yes - it passes without checking the thing the test was intended to check. > > > >>> m.assert_called() > > > > > >With the patch, everything starting with "assert" or "assret" (e.g. my > >example above) raises an AttributeError so these kind of issues can't > >happen. > > I get that part. It's checking for a naming convention for some purpose. > > What purpose? > >"To raise an AttributeError" ... but why? So you notice you have done a typo and your test will not actually verify what you want it to verify. Compare it with the behavior of a normal object - if you call a method which doesn't exist, it raises AttributeError. This isn't possible with Mock objects, as they are designed to support *any* call, and you can check the calls have happened after the fact. With the patch, if you call any method starting with "assert" which does not exist (assert_caled_with, assert_foobar, assert_called, etc.) this is assumed to be a mistake and you get an AttributeError so you notice there was a mistake. If you pass unsafe=True, you can still call mock.assert_foo() methods as usual and they will return a new Mock, just as calling, say, mock.spam() would. > >The thing people are discussing about is whether this should also > >happen if you do "m.assret_called_with()" (i.e. if this is a common > >enough typo to warrant a special exception), or if*only* things > >starting with assert_* are checked. > > > >The merged patch also treats "assret_*" as a typo, and some people > >think this is a wart/unnecessary/harmful and only "assert_*" should > >raise an AttributionError, i.e. the patch should be amended/reverted. > > I think it would be easy enough to revert, It' just a few line in the source > and docs. No big deal there. > > It's not clear why getting an AttributeError for methods beginning with > assert is needed, and how that exception is to be used. (Should it Bubble > up, or should it be caught and handled?) Note the discussion *isn't* about the
Re: [Python-Dev] How far to go with user-friendliness
* Ron Adam [2015-07-20 12:57:08 -0400]: > >It's "unsafe" because tests which: > > > >1) are using the assert_* methods of a mock, and > >2) where the programmer did a typo (assert_called() instead of > >assert_called_with() for example) > > > >do silently pass. > > And further down, you say... > > >Compare it with the behavior of a normal object - if you call a method > >which doesn't exist, it raises AttributeError. > > > >This isn't possible with Mock objects, as they are designed to support > >*any* call, and you can check the calls have happened after the fact. > > > And the docs say... > > """ > spec: This can be either a list of strings or an existing object (a class or > instance) that acts as the specification for the mock object. If you pass in > an object then a list of strings is formed by calling dir on the object > (excluding unsupported magic attributes and methods). Accessing any > attribute not in this list will raise an AttributeError. > """ > > So calling a method that doesn't exist on a mocked object will raise an > AttributeError if it is given a spec. > > But if you don't give it a spec, then a mispelling of *any* method will pass > silently. So it's not a problem limited to "assert" methods. > > It seems the obvious and best solution is to always use a spec. I agree - I always use mocks with autospec/spec, and I recommend doing that - I actually plan to write a plugin for pylint to enforce this. Still mistyping the assert methods seems to be a common issue, since (according to some other mail) a couple of bugs in OpenStack were found this way. But yeah - if your code under test has a typo, and you don't use spec/autospec, you might not notice as well - though in my experience you *usually* do, since the returned mock object doesn't behave in the way you expect it to. But yeah - always using (auto)spec is probably the best solution. > >>> m.assert_me() > Traceback (most recent call last): > File "", line 1, in > File > "/media/hda2/home/ra/Dev/python-dev/python3.5/cpython-master/Lib/unittest/mock.py", > line 583, in __getattr__ > raise AttributeError(name) > AttributeError: assert_me > > > Why is AttributeError raised here? Why are methods beginning with assert > special? (or "unsafe") Some things I can think of: - It's more likely that you use assert_called() instead of assert_called_with() accidentally than that you do a typo in your code under test. - If you do a typo in your code under test, a linter is more likely to find it than with mocks, because of their nature. - Other tests (even if they're manual ones) should probably discover the typo in your real code. The always-passing assert won't. Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpxz4InJiQIK.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?
* Nikolaus Rath [2015-07-21 20:23:15 -0700]: > On Jul 21 2015, Nick Coghlan wrote: > > All of this is why the chart that I believe should be worrying people > > is the topmost one on this page: > > http://bugs.python.org/issue?@template=stats > > > > Both the number of open issues and the number of open issues with > > patches are steadily trending upwards. That means the bottleneck in > > the current process *isn't* getting patches written in the first > > place, it's getting them up to the appropriate standards and applied. > > Yet the answer to the problem isn't a simple "recruit more core > > developers", as the existing core developers are *also* the bottleneck > > in the review and mentoring process for *new* core developers. > > As a random datapoint: > > Early last year I wanted get involved in CPython development. In the > next months I submitted and reviewed maybe 20 - 25 patches in the bug > tracker. After seeing all of them languish, I stopped submitting and > reviewing and just tried to get someone to look at the issues that I'd > worked on. Eventually, I managed to get almost all of them committed > (the last one sometime this February, after more than a year). However, > it was such an uphill battle just to get someone to look at my > contributions that I haven't touched the bugtracker ever since. > > [...] As another random datapoint: I have some (minor) things which I'd like to contribute to Python - and I never did. Seeing the number of open issues with patches just make me feel like it'd be a waste of time to contribute. It seems very plausible the patches will just be ignored without me putting effort in getting them noticed. I'm fine with revising things until people are happy, i.e. I don't just want to post a patch and disappear - but I don't want to fight to get any kind of response, and it looks to me like I'd have to. :-/ Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpzO6rKynhcM.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing tkinter on Linux
* R. David Murray [2015-08-27 15:00:40 -0400]: > It is possible to create a "virtual" X on an otherwise headless linux > system, but I've never tried to do it myself. If someone comes up > with a recipe we could add it to the devguide chapter on running > a buildbot. It's usually as easy as installing Xvfb and prepending "xvfb-run" to the command: $ export DISPLAY= $ python3 -m test -ugui test_tk test_ttk_guionly test_idle [1/3] test_tk test_tk skipped -- Tk unavailable due to TclError: couldn't connect to display "" [2/3] test_ttk_guionly test_ttk_guionly skipped -- Tk unavailable due to TclError: couldn't connect to display "" [3/3] test_idle 1 test OK. 2 tests skipped: test_tk test_ttk_guionly $ xvfb-run python3 -m test -ugui test_tk test_ttk_guionly test_idle [1/3] test_tk [2/3] test_ttk_guionly [3/3] test_idle All 3 tests OK. Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpr5QOltyNhr.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ConfigParser mangles keys with special chars
Hi,
I noticed configparser does behave in a surprising way when a key
has a special meaning in ini-format.
Consider this example:
>>> cp = configparser.ConfigParser()
>>> cp.read_dict({'DEFAULT': {';foo': 'bar'}})
>>> cp.write(sys.stdout)
[DEFAULT]
;foo = bar
Now when reading this again, ";foo = bar" will be a comment and
ignored. There's probably similiar behaviour in other corner cases
(like if you'd use "[foo]" as key for example).
While it seems ConfigParser doesn't do any escaping as all, I'm
thinking it should at least raise some exception when such a value is
trying to be set.
I'd expect writing something and then reading it back via the same
configparser to *always* result in the same data, as long as writing
worked without error.
Thoughts? Should I submit a bug report?
Florian
--
() ascii ribbon campaign - stop html mailwww.asciiribbon.org
/\ www.the-compiler.org | I love long mails http://email.is-not-s.ms/
To give happiness is to deserve happiness.
pgp8GxHvCh_Ah.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser mangles keys with special chars
* Florian Bruhin [2014-04-25 16:22:06 +0200]: > I noticed configparser does behave in a surprising way when a key > has a special meaning in ini-format. I've now submitted an issue here: http://bugs.python.org/issue21498 Florian -- () ascii ribbon campaign - stop html mailwww.asciiribbon.org /\ www.the-compiler.org | I love long mails http://email.is-not-s.ms/ Blessed are the forgetful: for they get the better even of their blunders. -- Nietzsche pgp8OOQCUnDP_.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character
* anatoly techtonik [2014-06-12 02:00:55 +0300]: > On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico wrote: > > > Why pass shell=True when executing a single > > command? I don't get it. > > > > I don't know about Linux, but on Windows programs are not directly > available as /usr/bin/python, so you need to find command in PATH > directories. Passing shell=True makes this lookup done by shell and not > manually. As it's been said, the whole *point* of shell=True is to be able to use shell features, so ^ being escaped automatically just would be... broken. How would I escape > then, for example ;) You basically have two options: - Do the lookup in PATH yourself, it's not like that's rocket science. I haven't checked if there's a ready function for it in the stdlib, but even when not: Get os.environ['PATH'], split it by os.pathsep, then for every directory check if your binary is in there. There's also some environment variable on Windows which contains the possible extensions for a binary in PATH, add that, and that's all. - Use shell=True and a cross-platform shell escape function. I've wrote one for a project of mine: [1] I've written some tests[2] but I haven't checked all corner-cases, so I can't guarantee it'll always work, as the interpretation of special chars by cmd.exe *is* black magic, at least to me. Needless to say this is probably the worse choice of the two. [1] http://git.the-compiler.org/qutebrowser/tree/qutebrowser/utils/misc.py?id=dffec73db76c867d261ec3416de011becb209f13#n154 [2] http://git.the-compiler.org/qutebrowser/tree/qutebrowser/test/utils/test_misc.py?id=dffec73db76c867d261ec3416de011becb209f13#n195 Florian -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpy7W5wzDW9z.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character
* Nikolaus Rath [2014-06-12 19:11:07 -0700]:
> "R. David Murray" writes:
> > Also notice that using a list with shell=True is using the API
> > incorrectly. It wouldn't even work on Linux, so that torpedoes
> > the cross-platform concern already :)
> >
> > This kind of confusion is why I opened http://bugs.python.org/issue7839.
>
> Can someone describe an use case where shell=True actually makes sense
> at all?
>
> It seems to me that whenever you need a shell, the argument's that you
> pass to it will be shell specific. So instead of e.g.
>
> Popen('for i in `seq 42`; do echo $i; done', shell=True)
>
> you almost certainly want to do
>
> Popen(['/bin/sh', 'for i in `seq 42`; do echo $i; done'], shell=False)
>
> because if your shell happens to be tcsh or cmd.exe, things are going to
> break.
My usecase is a spawn-command in a GUI application, which the user can
use to spawn an executable. I want the user to be able to use the
usual shell features from there. However, I also pass an argument to
that command, and that should be escaped.
Florian
--
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
I love long mails! | http://email.is-not-s.ms/
pgpsnlpNbDtTn.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Python.org downloads page and javascript
Hey Michael, On Thu, Nov 12, 2020 at 01:50:12PM +0100, Michael Felt wrote: > Not clear on where to report this - so I hope someone else sees the same and > can notify whoever needs to be notified. There's a "Submit Website Bug" in the footer of the website, taking you to the respective bugtracker: https://github.com/python/pythondotorg/issues I took the freedom to open an issue about it there: https://github.com/python/pythondotorg/issues/1672 Thanks for the report! Florian -- m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ signature.asc Description: PGP signature ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FBAMLHS7TWURKOCSMUJMD7WN3GLDRIX2/ Code of Conduct: http://python.org/psf/codeofconduct/
