Re: Who are the "spacists"?
On 3/19/17, Pavol Lisy wrote:
> On 3/18/17, Nathan Ernst wrote:
> PS. I am "spacist" :P but I feel this a little more aggressive than is
> necessary too:
>
>> Feel free to start your own discussion forum for your new programming
>> language that forbids spaces for indentation. That language will never
>> be Python, so please don't ask us to discuss it here.
>
> I think there could be enough time to deprecate now and forbid tabs
> (or spaces) as indentation in python4.
>
> That doesn't mean I propose that! I only think that this transition
> could be technically possible so discussion is not necessary useless.
Sorry here I forgot to mention that citation above is from Ben
Finney's mail and not from Nathan's!
Anyway. I just made a simple and primitive analyze:
re.findall('^ '...) and re.findall('^\t'...) for more than 100k
py-files discoverable by find / -name "*.py" on my (ubuntu 16.04)
computer.
Anybody could see that it incorrectly finds lines in multiline strings
(and has maybe much more flaws) but it could be probably still
interesting.
there are:
127 837 files where at least one line starts with space
2 273 files where at least one line starts with tab
1 192 files where are lines which starts with space and lines which
starts with tab
and there are:
35 144 893 lines which starts with space
428 160 lines which starts with tab
PL.
--
https://mail.python.org/mailman/listinfo/python-list
About linters and PEP-8
On 3/19/17, Chris Angelico wrote:
> On Sun, Mar 19, 2017 at 4:53 PM, Pavol Lisy wrote:
>> In case of spaces there is not discrepancy. pep8 and similar linters
>> could work fine without incompatible configurations.
> I don't like the pep8 tool; its name implies far more authority than
> it actually has. But if you look at the rules Python 3 applies, or
> Python 2 with "-tt", you should easily be able to comply.
There was discussion on python-idea about duplicity in dict definition.
{"a": "foo", "a": "bar"}
Conclusion was that it is not an error and anybody could use linters
for finding it. For example pylint could do it. Modern editors could
do linting parallel to editing and many people use it.
I think - I couldn't like everything what pep8 or pylint or any others
do. But it is some kind of responsibility to write codes, which do not
produce plenty of warnings. (because they could hide warning like
duplicity in dict)
And I think that significance of linters could grow as machine
learning will evolve. So if there is something wrong about PEP-8 maybe
there is some work for us to improve it.
PL.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Error installing python on Windows
Windows users (quite reasonably IMO) expect installs to "just work". If Python needs extra bits it should ask the user if it can go get them and if they say Yes it should do just that. (And this should actually work -- unlike maybe, the Python 3.5 Windows installer.) And as for searching Google for error messages, sure, experienced programmers do this, but many people come to Python as first-time programmers and don't realise. The fact that Michelle asked on this list shows that she made an effort that I suspect many people wouldn't bother making -- I can't help wondering how many new people have been lost to Python since the new installer. My experience has been that the new Python windows installer is less convenient than the old one. For example, with Python 3.6.0 64-bit on Windows the registry has to be fixed to be able to install popular packages like pywin32 (as well as less popular but excellent ones like apsw). Furthermore, the old and new installers offer the choice of "install just for you" or "install for everyone on the machine" but give no explanation of what difference this makes. If you install for everyone, you'll find that pip won't work. (OK, sure it'll work, providing you use the --user option, but how many people will realise that --user means "install for me"?) -- https://mail.python.org/mailman/listinfo/python-list
Re: About linters and PEP-8
On Sun, Mar 19, 2017 at 7:24 PM, Pavol Lisy wrote:
> On 3/19/17, Chris Angelico wrote:
>> On Sun, Mar 19, 2017 at 4:53 PM, Pavol Lisy wrote:
>
>>> In case of spaces there is not discrepancy. pep8 and similar linters
>>> could work fine without incompatible configurations.
>
>> I don't like the pep8 tool; its name implies far more authority than
>> it actually has. But if you look at the rules Python 3 applies, or
>> Python 2 with "-tt", you should easily be able to comply.
>
> There was discussion on python-idea about duplicity in dict definition.
>
>{"a": "foo", "a": "bar"}
>
> Conclusion was that it is not an error and anybody could use linters
> for finding it. For example pylint could do it. Modern editors could
> do linting parallel to editing and many people use it.
>
> I think - I couldn't like everything what pep8 or pylint or any others
> do. But it is some kind of responsibility to write codes, which do not
> produce plenty of warnings. (because they could hide warning like
> duplicity in dict)
>
> And I think that significance of linters could grow as machine
> learning will evolve. So if there is something wrong about PEP-8 maybe
> there is some work for us to improve it.
I'm not sure what your point is, or why you're responding to my post
to make it, so I'll clarify what I was saying:
The tool "pep8" is inappropriately named. No linter should use this
name. It implies a level of authority by linking with a very specific
document.
Now, the tool itself may well be a brilliant linter. That's fine, and
linters are excellent. But saying "a linter should be able to catch
this error" should not have people immediately turn around and say
"then PEP 8 should have a rule about this". And that's what seems to
happen when the tool and the document are too tightly linked.
http://rosuav.blogspot.com/2016/04/falsehoods-programmers-believe-about.html
PEP 8 is a very specific-purpose document: it is a set of rules which
govern the Python standard library. It so happens that, like many
other style guides, it can be adopted for other projects (just as the
airbnb style guide is adopted by a lot of JavaScript projects, and the
GNU style guide can be used for non-GNU projects), but it's still a
document aimed at humans. Here is its most important section:
https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds
Start by disconnecting the style guide from the linter. A piece of
code may fulfil every rule in your guide, but still be flagged by the
linter; or it can pass the linter's check, but still fail code review
because it violates a rule of style. (Example of the latter:
inconsistent naming of similar concepts. No linter can understand that
X.foo and Y.bar mean the same thing.) Enhancements to the style guide
and enhancements to the linter are thus completely independent, and
serve different (though related) purposes.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On 2017-03-18, Chris Angelico wrote: > On Sun, Mar 19, 2017 at 8:50 AM, Nathan Ernst wrote: >> My rule of thumb: tabs for indentation, spaces for alignment (i.e. trying >> to line up anything after a non-whitespace character on a single line). > > My rule of thumb: tabs for indentation, and don't align stuff after > non-whitespace :) Aligning columns in tables of data make it far easier to read/edit. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On 2017-03-18, Nathan Ernst wrote: > As I said earlier, where tabs are superior in that most code focused > editors (at least those worth using) allow you to adjust the width of the > tab. What about all other other text tools that _aren't_ 'code focused editors'? (e.g. grep, less, cat, awk, sed, a2ps, asciidoc, etc.) > I'm not aware of a single editor that allows you to adjust the > indentation of multiple spaces, let alone in the face of sources with mixed > space indentations in the same codebase. So the only thing that ever touches your code is that one editor? -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On 19 March 2017 at 02:05, Marko Rauhamaa wrote: > Chris Angelico : > >> On Sun, Mar 19, 2017 at 11:39 AM, Steve D'Aprano >> wrote: >>> Is it also ridiculous to use several newlines to space paragraphs >>> vertically? >> >> At least with paragraphs, we don't have eternal debates between people >> who think they should have four newlines, three newlines, or oh >> wait, there is debate between two and one > > Some people like fluffy source code: > > def f(): > > "doc" > > # Code follows > > x = calculate_some() > > return x + 1 > BTW, this was a good option, if one worked in such text modes where lines are so close to each other, that it was too hard to read anything. So it would be not 'fluffy' but actually normal spacing. Thankfully modern tools allow configuring the line spacing. -- https://mail.python.org/mailman/listinfo/python-list
Re: Where to start in the field of AI with Python
Robert O'Shea wrote: > I just want to get into the basics for the moment, eventually getting into > stuff like machine learning and NLP (Natural Language Processing). You cannot do wrong by starting with NLTK (https://www.nltk.org/) and scikit (http://scikit-learn.org/) -- --- | Radovan Garabík http://kassiopeia.juls.savba.sk/~garabik/ | | __..--^^^--..__garabik @ kassiopeia.juls.savba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread! -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs are a security vulnerabilty [was Re: Who are the "spacists"?]
On 19 March 2017 at 01:32, Steve D'Aprano wrote: > On Sun, 19 Mar 2017 03:30 am, Grant Edwards wrote: > >> tabs are a major security vulnerability and should be outlawed >> in all source code. > > > I've heard many arguments both in favour of and against tabs, but I've never > heard them described as a security vulnerability before. Let alone a major > one. > > Got a citation or some more information? Double that, I've googled and did not find anything. Also it is not clear, since vulnerability can be only for a particular executable that does something with a file, not the file itslef. I've heard some arguments aginst tabs also, but it turned out that most of them are even not real. -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On Mon, 20 Mar 2017 01:27 am, Grant Edwards wrote: > On 2017-03-18, Nathan Ernst wrote: > >> As I said earlier, where tabs are superior in that most code focused >> editors (at least those worth using) allow you to adjust the width of the >> tab. > > What about all other other text tools that _aren't_ 'code focused > editors'? (e.g. grep, less, cat, awk, sed, a2ps, asciidoc, etc.) I wonder whether the tabs versus spaces divide is closely aligned to the Windows versus Unix/Linux divide? It seems to me that Unix users are typically going to be using Unix tools which often assume spaces are used for indentation, and consequently cope badly with tabs. I maintain that makes them "broken" tools, but broken or not, that's the status quo and Unix users will simply deal with it by using spaces for indents. On the other hand, the typical Windows developer probably has little or no access to grep, less, sed, etc, and consequently doesn't fear using tabs in source code. Since nothing is going to touch it apart from either Notepad or the IDE, there's no problem with using tabs. Back when dinosaurs ruled the earth, and I had a Macintosh (classic OS, not OS X) it was normal to use tabs for indents. Likewise when I had a Windows machine. It was only when I moved to Linux that I had "tabs are bad, m'kay?" beaten into me, with the main justification being "tabs will break your tools". I'm not even sure that it is true that tabs will break the Unix toolset. But Unix users mostly *believe* it is true. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
Jon Ribbens writes: > On 2017-03-18, Grant Edwards wrote: >> On 2017-03-18, Mikhail V wrote: >>> How would one come to the idea to use spaces for indentation at all? >> >> Because tabs are a major security vulnerability and should be outlawed >> in all source code. > > You forgot to mention that tabs are carcinogenic, can be addictive, > and hate our freedoms. If we use them, the terrorists win. Tabs can > settle during transit, and may contain traces of nuts. Tabs should > not be folded, spindled or mutilated. Tabs are vicious if wounded. > Remember, kids: Just Say No to the Invisible Menace. And US government officials call them "alternative spaces". Enough said. -- Alain. P/S: just in case: https://www.jwz.org/doc/tabs-vs-spaces.html -- https://mail.python.org/mailman/listinfo/python-list
python script Non-ASCII character
hello i have create a python script when read some files using paths and do something with that files. if that paths for files is in english likes this "c:/my_path/english " then python script working but if that paths is in my main language or the path have some blank character then not working and i take that error : SyntaxError: Non-ASCII character '\xce' in file Untitled_.py on line 15, but no encoding declared; can i fix that in python 2.7.13 ? can i find some solution to python read paths in my main language or paths with blanks? -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On Mon, Mar 20, 2017 at 4:29 AM, Steve D'Aprano wrote: > I wonder whether the tabs versus spaces divide is closely aligned to the > Windows versus Unix/Linux divide? > > It seems to me that Unix users are typically going to be using Unix tools > which often assume spaces are used for indentation, and consequently cope > badly with tabs. I maintain that makes them "broken" tools, but broken or > not, that's the status quo and Unix users will simply deal with it by using > spaces for indents. Nope. I'm on Linux and I love my tabs. They play fine with grep, diff, etc. None of my tools has a problem with them. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python script Non-ASCII character
On Mon, Mar 20, 2017 at 4:38 AM, Xristos Xristoou wrote: > hello i have create a python script when read some files using paths and do > something with that files. > if that paths for files is in english likes this "c:/my_path/english " then > python script working but if that paths is in my main language or the path > have some blank character then not working and i take that error : > > SyntaxError: Non-ASCII character '\xce' in file Untitled_.py on line 15, but > no encoding declared; > > can i fix that in python 2.7.13 ? can i find some solution to python read > paths in my main language or paths with blanks? Based on your name, I'm guessing your main language is Greek. You might be using a character encoding of ISO-8859-7. Or you might be using UTF-8, which is a universal standard. Either way, the solution is to declare the encoding (as the error hints). The first thing I would recommend is switching to Python 3. This has a number of benefits relating to non-ASCII source code, including that UTF-8 is accepted automatically. That might fix your problem (\xce mentioned in the message is the beginning of the UTF-8 encoding for certain Greek letters), and if it doesn't, you can still declare the encoding to be ISO-8859-7. But go with UTF-8 if you possibly can. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python script Non-ASCII character
Τη Κυριακή, 19 Μαρτίου 2017 - 7:38:19 μ.μ. UTC+2, ο χρήστης Xristos Xristoou έγραψε: how to define my script with encoding of ISO-8859-7 or UTF-8?and for the blanks ? -- https://mail.python.org/mailman/listinfo/python-list
Re: About linters and PEP-8
On 3/19/2017 7:20 AM, Chris Angelico wrote: The tool "pep8" is inappropriately named. No linter should use this name. It implies a level of authority by linking with a very specific document. At Guido's request, the name was changed to 'pycodestyle'. See the note at the top of https://pep8.readthedocs.io/en/release-1.7.x/ This really should be noted also at the top of https://pypi.python.org/pypi/pep8/1.7.0 -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: python script Non-ASCII character
On Mon, Mar 20, 2017 at 6:48 AM, Xristos Xristoou wrote: > Τη Κυριακή, 19 Μαρτίου 2017 - 7:38:19 μ.μ. UTC+2, ο χρήστης Xristos Xristoou > έγραψε: > > how to define my script with encoding of ISO-8859-7 or UTF-8?and for the > blanks ? First, try using Python 3. Most of the time, that will be the best solution. I won't explain PEP 263 coding cookies until you've tried that :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: About linters and PEP-8
On Mon, Mar 20, 2017 at 6:50 AM, Terry Reedy wrote: > On 3/19/2017 7:20 AM, Chris Angelico wrote: > >> The tool "pep8" is inappropriately named. No linter should use this >> name. It implies a level of authority by linking with a very specific >> document. > > > At Guido's request, the name was changed to 'pycodestyle'. See the note at > the top of > https://pep8.readthedocs.io/en/release-1.7.x/ > > This really should be noted also at the top of > https://pypi.python.org/pypi/pep8/1.7.0 Oh, good. I heard that he requested it, but the place I looked was the PyPI landing page, so it looked like they were still using that name. Sadly, it's still going to be "pip install pep8", isn't it :( ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python script Non-ASCII character
On 3/19/2017 1:38 PM, Xristos Xristoou wrote:
hello i have create a python script when read some files using paths and do
something with that files.
if that paths for files is in english likes this "c:/my_path/english " then
python script working but if that paths is in my main language
Non-ascii in a pathname and non-ascii within a file are different
issues. On Windows, non-ascii in pathnames did not work consistently
until 3.2 or maybe 3.3.
> or the path have some blank character then not working
This should not be a problem. With 2.7.13:
>>> f = open('c:/program files/7-zip/readme.txt')
>>> print(f.read())
7-Zip 9.20
--
...
SyntaxError: Non-ASCII character '\xce' in file Untitled_.py on line 15, but no
encoding declared;
This is non-ascii within a file.
can i fix that in python 2.7.13 ? can i find some solution to python read paths
in my main language or paths with blanks?
Chris gave the answer for within-file non-ascii: provide the encoding.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Re: python script Non-ASCII character
Τη Κυριακή, 19 Μαρτίου 2017 - 7:38:19 μ.μ. UTC+2, ο χρήστης Xristos Xristoou έγραψε: yes that i know but i need python 2.7 for my task -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On 18 March 2017 at 22:50, Nathan Ernst wrote: > My issue with using spaces instead of tabs, is that, as mentioned earlier in > the thread, everyone has their own preferences on indentation. I've worked > on teams where different developers used 2, 3 & 4 spaces as indentation. > Obviously, if you're using spaces, several of the members will be unhappy. > > Tabs have the benefit that most editors used by developers allow the > adjustment of the width of a tab. If you use tabs, everyone can be happy > with the visual presentation of their code. > > My rule of thumb: tabs for indentation, spaces for alignment (i.e. trying to > line up anything after a non-whitespace character on a single line). > > Regards, > Nathan > Trying to line up things after a non-whitespace character, e.g. like this? myList = [ ["a", "b", "c"], ["mess up your alignment", "b", "c"], ["a", "b", "c"] ] Well there is no easy solution possible, especially if you want it to look exactly the same on all computers and editors. Before something like elastic tabstops will be a standard, it will continue to confuse people. Spaces are still one of the worst solutions, although it will give same results on monospaced editors. Changing a long string in above example means again ASCII art exercises, and it is not funny. I'd just leave it as is or use tabs, despite they can look different on other editor. Most importang thing, one should just stop thinking 'monospaced'. Monospaced text rendering is an artifact, which exist on a very short time period in history. At best, one should just imagine it should not exist, and is just a temporary inconvinience. Actually it lasts already much longer than I would expect. So for column alignment technically correct IMO are single tabs which are rendered depending on the context, i.e. this is like elastic tabstobs work, IIUC. On the other hand one should not edit spreadsheets in a text editor. If one does a lot of work on tables, then use appropriate softwre, e.g. Excell. Mikhail ine up anything after a non-whitespace character -- https://mail.python.org/mailman/listinfo/python-list
Re: python script Non-ASCII character
Τη Κυριακή, 19 Μαρτίου 2017 - 7:38:19 μ.μ. UTC+2, ο χρήστης Xristos Xristoou έγραψε: @Terry non-ascii in pathnames i need for ex :var1="C:\Users\username\Desktop\my language\mylanguage\myfile" and for the blank ? -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
Steve D'Aprano wrote: Unix tools which often assume spaces are used for indentation, and consequently cope badly with tabs. I maintain that makes them "broken" tools, They're not broken in the context of Unix, where there is a long-standing convention of assuming tab stops every 8 columns. From that point of view, tabs are not formatting instructions, but are just a way of compressing consecutive spaces. If tabs are used according to that convention, Unix tools cope with them just fine. I'm not even sure that it is true that tabs will break the Unix toolset. But Unix users mostly *believe* it is true. Tabs used according to non-Unix conventions will break Unix tools. But that doesn't mean the tools themselves are broken, any more than the fact that putting diesel fuel in a petrol car damages it means that petrol engines are broken. Python is in the awkward position of being expected to run on either petrol or diesel. It copes by requiring a particularly refined form of fuel, i.e. not mixing tabs and spaces. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
Mikhail V wrote: Monospaced text rendering is an artifact, which exist on a very short time period in history. At best, one should just imagine it should not exist, and is just a temporary inconvinience. Actually it lasts already much longer than I would expect. The fact that it *has* lasted so long might be telling us something. It has some advantages when machine processing text such as source code, where the semantic content is much more important than making it look pretty. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On 03/18/2017 05:01 PM, Nathan Ernst wrote: [...] Personally, I dislike any editor that, by default, changes my input to something else. If I hit tab, I want a tab to be inserted, by default. If I want something else, I'll change the configuration. A trivial point (and irrelevant)... The thing I find annoying about an editor set to expand tabs to spaces is that it takes one keypress to indent but four (or whatever) to unindent. -- -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On 2017-03-19, breamore...@gmail.com wrote: > On Sunday, March 19, 2017 at 9:54:52 PM UTC, Larry Hudson wrote: >> A trivial point (and irrelevant)... The thing I find annoying >> about an editor set to expand tabs to spaces is that it takes one >> keypress to indent but four (or whatever) to unindent. > > No, just about every editor that I've ever used has SHIFT-TAB set to > undo whatever TAB does. Not to mention plenty of editors (e.g. vim) will unindent when you press backspace. -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On 19 March 2017 at 22:54, Gregory Ewing wrote: > Mikhail V wrote: >> >> Monospaced text rendering is an artifact, >> which exist on a very short time period in history. >> At best, one should just imagine it should not exist, and is >> just a temporary inconvinience. Actually it lasts already much >> longer than I would expect. > > > The fact that it *has* lasted so long might be telling us > something. It has some advantages when machine processing > text such as source code, where the semantic content is much > more important than making it look pretty. > > -- > Greg If we speak about information reading, e.g. text or Python code, then I don't know of any helpful feature, except that characters are vertically aligned. And the feature is helpful only in this sense that I can align table columns with integer amount of spaces. The readability is however very poor and cannot be remedied with any tricks. Also if one *needs* monospaced for some reason, then one can always render units at equal distances, e.g. to compare two encrypted strings visually, but those are rare specific tasks. Obviously there are some technical advantages, e.g. the algorithms for tiled rendering are much simpler and respectively hardware can be much simpler / more performant. (E.g. tabloid in airport) Or, for example collision detection, which is part of mouse text selection algorithm is much simpler, etc. These are IMO main reasons why it still often used. Sadly, many people believe that a code editor should be monospaced, but generally that does not have any sense. Mikhail -- https://mail.python.org/mailman/listinfo/python-list
Re: cryptography default_backend is "hazmat"?
On Sunday, 19 March 2017 03:16:17 UTC, Arthur Darcet wrote: > On Sat, 18 Mar 2017 at 23:29, Ian Pilcher wrote: > > > On 03/18/2017 05:15 PM, Chris Angelico wrote: > > > So the question is: How well do you trust the examples? Are they > > > likely to be instructing you in a safe way to use this > > > potentially-dangerous module? > > > > But as far as I can tell, there's no way to use many of the non-hazmat > > functions (e.g. parsing a certificate) without a backend, and all of the > > backends are "hazmat". > > > > So what's the point of marking something as hazmat, if a large portion > > of the rest of the module can't be used without it? > > > > If I'm not mistaken, the hazmat module contains functions that are easy to > misuse, which is why they are hazardous. > Using those same functions through the "safe" part of the library isn't > dangerous I do tend to agree with the OP. As someone who *definitely* doesn't claim to be a security expert, I'd prefer to stick solely to the "for non-expert users only" part of the module. As far as I can see, that part includes only: 1. Fernet symmetric encryption, which is fine, but needs me to manage the key safely (and offers no help in doing that) 2. X509, whose docs are a reference (that you need to understand X509 to follow) and a couple of tutorials on generating/requesting keys. Nothing on using X509 for encryption. Some of the "obvious" things I'd like to be able to do (e.g., create a message digest, public key cryptography, hashing passwords for storage) are all in the "hazmat" part of the documentation. So I'm left with the choice of using cryptography and explicitly using parts documented as not suitable for me, or using something else that claims to be robust (but which may not be, depending on whether I trust the author, or prefer to trust the PyCA, who seem to be implying that the subject is too complex for them to be able to provide a non-expert-friendly version, so how come other authors can?) FWIW, for the 3 examples I gave above, quick Google searches found: * message digest - the stdlib hashlib module * public key - pycrypto * password hashes - passlib I have no idea whether these are "acceptable" solutions, but I'd tend to use them in preference to the cryptography library, simply because they don't claim that the functions needed are "dangerous to use". Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
Gregory Ewing : > Steve D'Aprano wrote: >> Unix tools which often assume spaces are used for indentation, and >> consequently cope badly with tabs. I maintain that makes them >> "broken" tools, > > They're not broken in the context of Unix, where there is a > long-standing convention of assuming tab stops every 8 columns. From > that point of view, tabs are not formatting instructions, but are just > a way of compressing consecutive spaces. If tabs are used according to > that convention, Unix tools cope with them just fine. Correct, the 8-column interpretation is the only defensible use for tabs. However, since that use is completely redundant, better not use them at all. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: About linters and PEP-8
On 3/19/2017 3:57 PM, Chris Angelico wrote: On Mon, Mar 20, 2017 at 6:50 AM, Terry Reedy wrote: On 3/19/2017 7:20 AM, Chris Angelico wrote: The tool "pep8" is inappropriately named. No linter should use this name. It implies a level of authority by linking with a very specific document. At Guido's request, the name was changed to 'pycodestyle'. See the note at the top of https://pep8.readthedocs.io/en/release-1.7.x/ This really should be noted also at the top of https://pypi.python.org/pypi/pep8/1.7.0 Oh, good. I heard that he requested it, but the place I looked was the PyPI landing page, so it looked like they were still using that name. Sadly, it's still going to be "pip install pep8", isn't it :( That should get the last pep8 from early 2016. I presume the current pycodestyle needs C:\Users\Terry>py -m pip install pycodestyle Collecting pycodestyle Downloading pycodestyle-2.3.1-py2.py3-none-any.whl (45kB) 100% || 51kB 501kB/s Installing collected packages: pycodestyle Successfully installed pycodestyle-2.3.1 -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On Mon, Mar 20, 2017 at 9:48 AM, Mikhail V wrote: > [regarding monospaced text] > Or, for example collision detection, which is part > of mouse text selection algorithm is much simpler, etc. > These are IMO main reasons why it still often used. I work extensively with MUDs, where traditionally ASCII text is monospaced. It's normal to create alignment with spaces, and for tabs to represent eight-space positions (so "abc\td" will take up nine slots of width). But in the world of Unicode, it's not that simple. Some text runs right-to-left, some characters have different widths assigned, some have no width at all. My program has to cope with all of these, including when you use the mouse to select text. Monospacing is not about making it easier for the program; it's about keeping things the way the human expects. I do not ever want my MUDs or my shells to run with classic "proportionally-spaced" fonts, but I do want them to be able to cope with RTL text etc. And they can. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On 19/03/17 22:29, Jon Ribbens wrote:
On 2017-03-19, breamore...@gmail.com wrote:
On Sunday, March 19, 2017 at 9:54:52 PM UTC, Larry Hudson wrote:
A trivial point (and irrelevant)... The thing I find annoying
about an editor set to expand tabs to spaces is that it takes one
keypress to indent but four (or whatever) to unindent.
No, just about every editor that I've ever used has SHIFT-TAB set to
undo whatever TAB does.
Not to mention plenty of editors (e.g. vim) will unindent when you
press backspace.
I don't think that's strictly true. If you have just indented with a tab
character, then backspace will delete that tab character. But, if you
indent with either 4 spaces or use the Tab key with "expandtab" enabled,
then it will just delete the right-most space character.
The closest I've come to an "unindent" in vim so far is Ctrl-D, which
backs up one "shift width's" worth.
For sanity, in 'vim', I always use (for my own Python code, at least):
:set sw=4 ts=4 expandtabs
That way, all tab keypresses insert 4 spaces instead of a tab and the
shift operations ('<' and '>') will do the same. This also means the
"back up one shift-width" command (Ctrl-D) is the same as a "dedent".
If you also use the autoindent setting (:set ai), then writing code is
as easy as pressing enter and Tab to start a new suite, enter only to
continue a suite, and enter and Ctrl-D to drop back to the outer suite.
E.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
Larry Hudson :
> A trivial point (and irrelevant)... The thing I find annoying about an
> editor set to expand tabs to spaces is that it takes one keypress to
> indent but four (or whatever) to unindent.
In emacs' Python mode, if I have entered:
env.SharedLibrary('custom', [ 'a.c',
▯
and press Tab, the cursor moves to the right position:
env.SharedLibrary('custom', [ 'a.c',
▯
Now, pressing Backspace once (or Tab once more), I get:
env.SharedLibrary('custom', [ 'a.c',
▯
After a second Backspace (or a third Tab):
env.SharedLibrary('custom', [ 'a.c',
▯
and so on, 4 columns at a time.
I have told emacs not to use HT characters.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: python script Non-ASCII character
On 2017-03-19 20:10, Xristos Xristoou wrote: Τη Κυριακή, 19 Μαρτίου 2017 - 7:38:19 μ.μ. UTC+2, ο χρήστης Xristos Xristoou έγραψε: @Terry non-ascii in pathnames i need for ex :var1="C:\Users\username\Desktop\my language\mylanguage\myfile" and for the blank ? Your choices are: 1. Raw string literals: var1 = r"C:\Users\username\Desktop\my language\mylanguage\myfile" However, the literal shouldn't end with a backslash, so, for example, r"C:\" _won't_ work. 2. Slashes: var1 = "C:/Users/username/Desktop/my language/mylanguage/myfile" 3. Doubled backslashes: var1 = "C:\\Users\\username\\Desktop\\my language\\mylanguage\\myfile" If the path contains non-ASCII characters (for example, Greek letters), it's much better to use Unicode instead. If you're using Unicode string literals, your choices are: 1. Raw string literals: var1 = ur"C:\Users\username\Desktop\η γλωσσα μου\mylanguage\myfile" However, the literal shouldn't end with a backslash, so, for example, ur"C:\" _won't_ work. 2. Slashes: var1 = u"C:/Users/username/Desktop/η γλωσσα μου/mylanguage/myfile" 3. Doubled backslashes: var1 = u"C:\\Users\\username\\Desktop\\η γλωσσα μου\\mylanguage\\myfile" Just remember to specify the encoding as the first or second line: # -*- coding: utf-8 -*- and save the file in that encoding (UTF-8, in this case). -- https://mail.python.org/mailman/listinfo/python-list
Re: python script Non-ASCII character
On Mon, 20 Mar 2017 06:48 am, Xristos Xristoou wrote: > Τη Κυριακή, 19 Μαρτίου 2017 - 7:38:19 μ.μ. UTC+2, ο χρήστης Xristos > Xristoou έγραψε: > > how to define my script with encoding of ISO-8859-7 or UTF-8?and for the > blanks ? First you need to know whether your editor is saving the file using UTF-8 or ISO-8859-7. What editor are you using? Set your editor to use UTF-8. That is the best option. In your script, put: # -*- coding: utf-8 -*- as the **very first or second** line of the script. It must be at the beginning. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: About linters and PEP-8
On Mon, Mar 20, 2017 at 10:01 AM, Terry Reedy wrote: >>> At Guido's request, the name was changed to 'pycodestyle'. See the note >>> at >>> the top of >>> https://pep8.readthedocs.io/en/release-1.7.x/ >>> >>> This really should be noted also at the top of >>> https://pypi.python.org/pypi/pep8/1.7.0 >> >> >> Oh, good. I heard that he requested it, but the place I looked was the >> PyPI landing page, so it looked like they were still using that name. >> >> Sadly, it's still going to be "pip install pep8", isn't it :( > > > That should get the last pep8 from early 2016. I presume the current > pycodestyle needs > > C:\Users\Terry>py -m pip install pycodestyle In the docs link you posted, scroll down a bit: https://pep8.readthedocs.io/en/release-1.7.x/intro.html#installation Or maybe that's outdated and also needs to be fixed? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On 2017-03-19, Erik wrote: > On 19/03/17 22:29, Jon Ribbens wrote: >> Not to mention plenty of editors (e.g. vim) will unindent when you >> press backspace. > > I don't think that's strictly true. If you have just indented with a tab > character, then backspace will delete that tab character. But, if you > indent with either 4 spaces or use the Tab key with "expandtab" enabled, > then it will just delete the right-most space character. The option you want is "smarttab", then it will behave as I describe. (Or install the "vim-sensible" settings, which I highly recommend.) -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On Mon, 20 Mar 2017 09:50 am, Marko Rauhamaa wrote: > the 8-column interpretation is the only defensible use for > tabs. Oh, that's a law of physics is it? "8 columns per tab" is one of the fundamental mathematical or physical constants baked into the nature of reality, like π ≈ 3.14159... e ≈ 2.71828... Feigenbaum constant δ ≈ 4.66920... gravitational constant G ≈ 6.673e-11 N m**2 kg**-2 fine structure constant α ≈ 7.297351e-3 etc. And here I was, in my ignorance, thinking that it was a mere convention, something that could trivially be made a config option for those tools which actually needed it: --tabwidth=4 But I guess that's just as silly as redefining π as 3 exactly. -- Steve 299792.458 km/s — not just a good idea, it’s the law! -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On Mon, Mar 20, 2017 at 10:55 AM, Steve D'Aprano wrote: > Oh, that's a law of physics is it? "8 columns per tab" is one of the > fundamental mathematical or physical constants baked into the nature of > reality, like > > π ≈ 3.14159... > e ≈ 2.71828... > Feigenbaum constant δ ≈ 4.66920... > gravitational constant G ≈ 6.673e-11 N m**2 kg**-2 > fine structure constant α ≈ 7.297351e-3 > > etc. And here I was, in my ignorance, thinking that it was a mere > convention, something that could trivially be made a config option for > those tools which actually needed it: > > --tabwidth=4 > > But I guess that's just as silly as redefining π as 3 exactly. Yes. Actually, all of those constants are themselves defined in terms of the width of a tab; if you change a tab to be seven spaces, e would become 2.3785. That's just how the world works. Actually, when I first met tabs, they were defined in centimeters. Aside from the fact that they really should have been defined in millimeters, I fully support that broad concept. (And they weren't defined as "every 2.5 cm" necessarily; the default was for them to repeat, but if you wanted, you could have them at 2.5, then 5.0, then 6.0, then 9.0, etc, etc, etc.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On Mon, 20 Mar 2017 06:00 am, Chris Angelico wrote: > On Mon, Mar 20, 2017 at 4:29 AM, Steve D'Aprano > wrote: >> I wonder whether the tabs versus spaces divide is closely aligned to the >> Windows versus Unix/Linux divide? >> >> It seems to me that Unix users are typically going to be using Unix tools >> which often assume spaces are used for indentation, and consequently cope >> badly with tabs. I maintain that makes them "broken" tools, but broken or >> not, that's the status quo and Unix users will simply deal with it by >> using spaces for indents. > > Nope. I'm on Linux and I love my tabs. They play fine with grep, diff, > etc. None of my tools has a problem with them. Hence my comment: "I'm not even sure that it is true that tabs will break the Unix toolset. But Unix users mostly believe it is true." Perhaps I should have specified, *many* Unix users believe. Or "some" Unix users. Or "the guys I work with". Or perhaps "just that one guy": here is JMZ, who says it is "impossible" to do anything with a text file unless you know what a TAB character represents: I just care that two people editing the same file use the same interpretations, and that it's possible to look at a file and know what interpretation of the TAB character was used, because otherwise it's just impossible to read. https://www.jwz.org/doc/tabs-vs-spaces.html Jamie Zawinski is a clever man, but I've read that document probably a dozen times over the years, and I still don't understand it. If I indent something using tab characters: indent 1 indent 2 indent 1 again why does JMZ need to know how many columns *I* choose to use to display this? I could use 4 columns per tab, or 64, and not only is the source text identical but the interpretation in terms of *indent levels* is the same. And that's the only interpretation that really matters: whether something is indented once, or twice, not the physical number of columns that takes up on *my* screen. JMZ's "solution" is to ban TAB characters from source files. I don't understand why he thinks that solves *anything*. If anything, it makes it worse: for example, in the above quoted paragraph, I deliberately indented the quote by *two* indents, not one, but using a spaces. How can JMZ distinguish between "one 8-column indent" and "two 4-column indent" when spaces are used instead of tabs? I don't think you can. I think he is working on the unstated assumption that indentation will never increase by more than one level. If so, then he can easily read: indented text more indented text as a single 8-column indent. And he'll usually be right, until he keeps reading and find: still more indented text outdented by half a level text? I find myself using spaces because it is the path of least resistance, and the tools I use make it tolerable. But for the life of me I still cannot understand the *logical argument* against tabs. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On Mon, Mar 20, 2017 at 11:42 AM, Steve D'Aprano wrote: > Or perhaps "just that one guy": here is JMZ, who says it is "impossible" to > do anything with a text file unless you know what a TAB character > represents: > > I just care that two people editing the same file use the same > interpretations, and that it's possible to look at a file and > know what interpretation of the TAB character was used, because > otherwise it's just impossible to read. > > https://www.jwz.org/doc/tabs-vs-spaces.html > > > Jamie Zawinski is a clever man, but I've read that document probably a dozen > times over the years, and I still don't understand it. If I indent > something using tab characters: > > indent 1 > indent 2 > indent 1 again > > why does JMZ need to know how many columns *I* choose to use to display > this? It's the same problem that you get when you put byte value 97 into a file and it's impossible to know whether you meant for it to be displayed in Courier or Times Roman. When you care about that level of detail, *you're doing it wrong*. Text files are not intended to convey exact pixel arrangements - they're for carrying linguistic information. In a text file, horizontal tab means "move horizontally". It doesn't mean "move eight times the width of one standard character" (which is less standard than a standard drink), and it doesn't mean "move 30mm", and it certainly doesn't mean "move into debate mode against people who use spaces". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Who are the "spacists"?
On 19/03/17 23:23, Jon Ribbens wrote: On 2017-03-19, Erik wrote: On 19/03/17 22:29, Jon Ribbens wrote: Not to mention plenty of editors (e.g. vim) will unindent when you press backspace. I don't think that's strictly true. If you have just indented with a tab character, then backspace will delete that tab character. But, if you indent with either 4 spaces or use the Tab key with "expandtab" enabled, then it will just delete the right-most space character. The option you want is "smarttab", then it will behave as I describe. You're quite right (as was I because you didn't mention it wasn't out-of-the-box functionality ;)). I may well add that setting to my .vimrc, but FWIW, the Ctrl-D thing harks back to the original "vi" which I grew up on, so although I may add that setting, my muscle memory will probably still have me pressing Ctrl-D forever ;) (Or install the "vim-sensible" settings, which I highly recommend.) I have no interest in making my settings "sensible", thank you very much :D Thanks though - it's always nice to learn another way to hone things just as one likes them ... E. -- https://mail.python.org/mailman/listinfo/python-list
how to corss-compile azure-iot-sdk-python
Hi: I want to port the 'azure-iot-sdk-python' to my router(arm platform). How can i achieve this? -- https://mail.python.org/mailman/listinfo/python-list
Re: python script Non-ASCII character
On Sun, Mar 19, 2017 at 11:06 PM, MRAB wrote: > > If you're using Unicode string literals, your choices are: > > 1. Raw string literals: > > var1 = ur"C:\Users\username\Desktop\η γλωσσα μου\mylanguage\myfile" Raw unicode literals are practically useless in Python 2. They're not actually raw because \u and \U are still parsed as Unicode escapes, e.g. ur"C:\Users" and ur"C:\users" are syntax errors. > 2. Slashes: > > var1 = u"C:/Users/username/Desktop/η γλωσσα μου/mylanguage/myfile" I prefer to normalize a path with os.path.normpath, or pathlib.Path in Python 3. This converts slashes to backslashes to get a canonical Windows path. IMO, it's also visually better in a text representation or error messages. Otherwise at runtime joined paths often end up with mixed slashes, which to me is ugly. -- https://mail.python.org/mailman/listinfo/python-list
Re: About linters and PEP-8
On 3/19/2017 7:26 PM, Chris Angelico wrote: In the docs link you posted, scroll down a bit: https://pep8.readthedocs.io/en/release-1.7.x/intro.html#installation Or maybe that's outdated and also needs to be fixed? It is up to date for the latest outdated 'pep8'. It is needed for someone replicating setups that have not upgraded. There are still occasional downloads for PIL even though essentially superceded by pillow years ago. https://pycodestyle.readthedocs.io/en/latest/ tells how to install the renamed and currently maintained module. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: About linters and PEP-8
On Mon, Mar 20, 2017 at 1:52 PM, Terry Reedy wrote: > On 3/19/2017 7:26 PM, Chris Angelico wrote: > >> In the docs link you posted, scroll down a bit: >> >> https://pep8.readthedocs.io/en/release-1.7.x/intro.html#installation >> >> Or maybe that's outdated and also needs to be fixed? > > > It is up to date for the latest outdated 'pep8'. It is needed for someone > replicating setups that have not upgraded. There are still occasional > downloads for PIL even though essentially superceded by pillow years ago. > > https://pycodestyle.readthedocs.io/en/latest/ > tells how to install the renamed and currently maintained module. Gotcha. Maybe the note in the old docs needs to be clearer in saying "this module is now unmaintained - see the new module, install that, yada yada". ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python script Non-ASCII character
On 2017-03-20 02:50, eryk sun wrote: On Sun, Mar 19, 2017 at 11:06 PM, MRAB wrote: If you're using Unicode string literals, your choices are: 1. Raw string literals: var1 = ur"C:\Users\username\Desktop\η γλωσσα μου\mylanguage\myfile" Raw unicode literals are practically useless in Python 2. They're not actually raw because \u and \U are still parsed as Unicode escapes, e.g. ur"C:\Users" and ur"C:\users" are syntax errors. Thanks for the correction. I haven't used Python 2 for a long time (apart from running the unit tests when I make a new release of the regex module)! 2. Slashes: var1 = u"C:/Users/username/Desktop/η γλωσσα μου/mylanguage/myfile" I prefer to normalize a path with os.path.normpath, or pathlib.Path in Python 3. This converts slashes to backslashes to get a canonical Windows path. IMO, it's also visually better in a text representation or error messages. Otherwise at runtime joined paths often end up with mixed slashes, which to me is ugly. -- https://mail.python.org/mailman/listinfo/python-list
