[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/
Re: [Python-Dev] Testing tkinter on Linux
* R. David Murray rdmur...@bitdance.com [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
Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?
* Nikolaus Rath nikol...@rath.org [2015-07-21 20:23:15 -0700]: On Jul 21 2015, Nick Coghlan ncogh...@gmail.com 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] How far to go with user-friendliness
* Ron Adam ron3...@gmail.com [2015-07-19 18:06:22 -0400]: On 07/19/2015 02:33 PM, Florian Bruhin wrote: * Ron Adamron3...@gmail.com [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() Mock name='mock.assert_called()' id='140277467876152' 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 fact that assert-methods should raise AttributeError! The patch also does the same with assret. At least if I understand things correctly, the discussion is whether *only* assert* should be handled as a typo, or assret* too. The exception should bubble up, as the whole point of it is to tell you you did a typo and your test is broken. 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/ pgpMO8rT2PffT.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 ron3...@gmail.com [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 stdin, line 1, in module 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 far to go with user-friendliness
* Ron Adam ron3...@gmail.com [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() Mock name='mock.foo()' id='140277502245632' 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() Mock name='mock.assert_called()' id='140277467876152' 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
* Steven D'Aprano st...@pearwood.info [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() Mock name='mock.eggs()' id='140373912833384' m.bacon() Mock name='mock.bacon()' id='140373910240616' 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() Mock name='mock.assert_caled_with()' id='140373910240672' 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] 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 ncogh...@gmail.com [2015-06-01 00:15:01 +1000]: On 31 May 2015 at 19:07, Ludovic Gasc gml...@gmail.com 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] anomaly
* Mark Rosenblitt-Janssen dreamingforw...@gmail.com [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 dreamingforw...@gmail.com [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] What's missing in PEP-484 (Type hints)
* Dima Tisnek dim...@gmail.com [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] Type hints -- a mediocre programmer's reaction
* Wolfgang Langner tds333+py...@gmail.com [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] Possible wrong behavior of the dict?
* Zaur Shibzukhov szp...@gmail.com [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] str.lstrip bug?
* lou xiao lox.x...@gmail.com [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] Fwd: str(IntEnum)
* Demian Brecht demianbre...@gmail.com [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', ''))
'ProtocolError for url: 42 msg’
str(URLError('reason'))
'urlopen error reason’
str(Cookie(0, '', '', '4', '', '', '', '', '', '', '', 0, '', '', '', ''))
'Cookie = for :4'
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)
'object object at 0x7f799a8a9070'
repr(foo)
'object object at 0x7f799a8a9070'
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] subprocess shell=True on Windows doesn't escape ^ character
* Nikolaus Rath nikol...@rath.org [2014-06-12 19:11:07 -0700]:
R. David Murray rdmur...@bitdance.com 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
Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character
* anatoly techtonik techto...@gmail.com [2014-06-12 02:00:55 +0300]: On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico ros...@gmail.com 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] ConfigParser mangles keys with special chars
* Florian Bruhin m...@the-compiler.org [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
[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
