Re: Python indentation (3 spaces)

[Christian Gollwitzer]

Am 14.10.18 um 02:45 schrieb Grant Edwards:

On 2018-10-13, Peter J. Holzer  wrote:



For "just use tabs" to work, all of those tools would have to
magically recognize that they're looking at Python source and adjust
the tab size accordingly.  That isn't going to happen.


Well, no. The idea of "just use tabs" isn't have a different tab width
per language, but a different tab width per user.


You work in a different environment than I do.  for me, tab width
varies from one project to another (sometimes even in the same
language).  I don't get to pick just one tab width.


But if you use only tabs for indentation, the tab width setting simply 
does not matter. I'm in favour of using only tabs.


There is a disadvantage only if you try to align something which is NOT 
an indentation level, e.g. when there are big string constants or list 
constants etc.


Christian


--
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Peter J. Holzer]

On 2018-10-14 00:45:49 +, Grant Edwards wrote:
> On 2018-10-13, Peter J. Holzer  wrote:
> >
> >> For "just use tabs" to work, all of those tools would have to
> >> magically recognize that they're looking at Python source and adjust
> >> the tab size accordingly.  That isn't going to happen.
> >
> > Well, no. The idea of "just use tabs" isn't have a different tab width
> > per language, but a different tab width per user.
> 
> You work in a different environment than I do.  for me, tab width
> varies from one project to another (sometimes even in the same
> language).  I don't get to pick just one tab width.

You probably don't because you use spaces, not tabs.

If everybody used tabs, why would anyone care about your tab width?
Unless they look over your shoulder while you are typing, they won't
even know how wide your tabs are.

(That said, I personally prefer shorter indentation for marked up text
(like HTML or LaTeX) than for programming languages. But I could live
with the same indentation if necessary (and of course it isn't
necessary: Any decent editor has to be able detect the file type anyway
for syntax highlighting so it can adjust the display of tabs, too.))

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-Dev] [RELEASE] Python 3.7.1rc2 and 3.6.7rc2 now available for testing

[Ray Donnelly]

Hi Ned,

I tried to report this on bpo, but it's not letting me log in for some reason.

I ran into a problem trying to build 3.7.1-rc2 on macOS for Anaconda
Distribution. I debugged it a little so hopefully this is useful?

The error is:

checking whether float word ordering is bigendian... unknown

This happens because by default, clang on macOS still generates 'fat'
binaries so the greps introduced in
https://github.com/python/cpython/commit/2a9c3805ddedf282881ef7811a561c70b74f80b1
find both noonsees and seesnoon.

If we add `-arch x86_64` to our `CFLAGS` then we get a successful
build, so perhaps this should be added in the configure stuff when we
detect macOS?

Best regards,

Ray Donnelly,
Anaconda Inc,
On Sat, Oct 13, 2018 at 10:51 PM Ned Deily  wrote:
>
> Python 3.7.1rc2 and 3.6.7rc2 are now available. 3.7.1rc2 is a release
> preview of the first maintenance release of Python 3.7, the latest
> feature release of Python. 3.6.7rc2 is a release preview of the next
> maintenance release of Python 3.6, the previous feature release of
> Python. Assuming no further critical problems are found prior to
> 2018-10-20, no code changes are planned between these release
> candidates and the final releases. These release candidates are
> intended to give you the opportunity to test the new security and bug
> fixes in 3.7.1 and 3.6.7. We strongly encourage you to test your
> projects and report issues found to bugs.python.org as soon as
> possible. Please keep in mind that these are preview releases and,
> thus, their use is not recommended for production environments.
>
> You can find these releases and more information here:
> https://www.python.org/downloads/release/python-371rc2/
> https://www.python.org/downloads/release/python-367rc2/
>
> --
>   Ned Deily
>   n...@python.org -- []
>
> ___
> Python-Dev mailing list
> python-...@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/mingw.android%40gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Grant Edwards]

On 2018-10-14, Christian Gollwitzer  wrote:
> Am 14.10.18 um 02:45 schrieb Grant Edwards:
>> On 2018-10-13, Peter J. Holzer  wrote:
>>>
 For "just use tabs" to work, all of those tools would have to
 magically recognize that they're looking at Python source and adjust
 the tab size accordingly.  That isn't going to happen.
>>>
>>> Well, no. The idea of "just use tabs" isn't have a different tab width
>>> per language, but a different tab width per user.
>> 
>> You work in a different environment than I do.  for me, tab width
>> varies from one project to another (sometimes even in the same
>> language).  I don't get to pick just one tab width.
>
> But if you use only tabs for indentation, the tab width setting simply 
> does not matter.

> There is a disadvantage only if you try to align something which is NOT 
> an indentation level, e.g. when there are big string constants or list 
> constants etc.

Exactly.  In my experience, people who use tabs for indentation always
end up using them for other things as well: aligning comments or columns
in data tables, etc.

-- 
Grant

-- 
https://mail.python.org/mailman/listinfo/python-list

Fwd: socket: Too many open files

[Shakti Kumar]

>On 13Oct2018 14:10, Shakti Kumar  wrote:
>>I’m running a script which basically does a traceroute to the list of
>>hosts
>>provided, and then pulls up some info by logging in to gateways in the
path.
>>I am running this script for a list of almost 40k hosts in our data
centers.
>>Also, I am using commands module to get the traceroute output.
>>
>>out = commands.getstatusoutput('traceroute ' + ip)
>>
>>However I observe that this particular line is failing with socket error
>>after I reach some 5k to 6k hosts.
>>I know commands module is using pipes to execute the given command and
this
>>is one reason for exhaustion of file descriptors.
>>Any suggestions for improving this and getting a workaround?

>I'd figure out where your file descriptors are going.

>Is traceroute leaving sockets littering your system? If you're on Linux
>this command:

>  netstat -anp

>will show you all the sockets, their state, and the pids of the
>processes which own them. Does your script cause sockets to accrue after
>the traceroutes?

>If you write a trivial shell script to do the traceroutes:

>while read ip
>do
>traceroute $ip
>  done does it also exhibit the problem?

>The if doesn't, then traceroute may not be the problem and something
>else is leaking file descriptors.

>In fact, given that it is file descriptors, maybe sockets are not what
>is leaking?

>From another terminal, see what your Python programme has open when this
>happens with "lsof -n -p pid-of-python-programme". Maybe the leaks are
>pipes, or connections from your "logging in to gateways in the path"
>code. It may be as simple as you not closing files or connections.

>Cheers,
>Cameron Simpson 

Thanks Cameron, I still cant get over the fact that you were able to pin
point the issue even without looking at my code XD
Indeed when I started looking for sockets, I realised I was not closing
connections to ACI hosts in our datacentres, and the error was starting to
pop up at around 2900 to 3k TCP connections open to the hosts. XD

Thanks Jonathan for pointing me to more apt functions. It helped a lot :)

Regards,
Shakti.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Chris Angelico]

On Mon, Oct 15, 2018 at 1:35 AM Grant Edwards  wrote:
>
> On 2018-10-14, Christian Gollwitzer  wrote:
> > Am 14.10.18 um 02:45 schrieb Grant Edwards:
> >> On 2018-10-13, Peter J. Holzer  wrote:
> >>>
>  For "just use tabs" to work, all of those tools would have to
>  magically recognize that they're looking at Python source and adjust
>  the tab size accordingly.  That isn't going to happen.
> >>>
> >>> Well, no. The idea of "just use tabs" isn't have a different tab width
> >>> per language, but a different tab width per user.
> >>
> >> You work in a different environment than I do.  for me, tab width
> >> varies from one project to another (sometimes even in the same
> >> language).  I don't get to pick just one tab width.
> >
> > But if you use only tabs for indentation, the tab width setting simply
> > does not matter.
>
> > There is a disadvantage only if you try to align something which is NOT
> > an indentation level, e.g. when there are big string constants or list
> > constants etc.
>
> Exactly.  In my experience, people who use tabs for indentation always
> end up using them for other things as well: aligning comments or columns
> in data tables, etc.
>

Well, I don't, and I DO use tabs for indentation. So how about we
restrict this discussion to indentation, and not worry about other
things people might also use tabs for?

Tabs for indentation have semantic meaning. Top-level has zero tabs.
One indentation level is represented by one tab. Two indentation
levels? Two tabs. It's about as perfect a representation as you could
hope for. If you like your indentation levels to be as wide as four
spaces, you can have that. I could have them at eight, and it wouldn't
make a difference. And if someone messes up their code by using tabs
to align all their comments, reject that code at code review time.
This ain't rocket science.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Marko Rauhamaa]

Chris Angelico :

> Tabs for indentation have semantic meaning. Top-level has zero tabs.
> One indentation level is represented by one tab. Two indentation
> levels? Two tabs. It's about as perfect a representation as you could
> hope for. If you like your indentation levels to be as wide as four
> spaces, you can have that. I could have them at eight, and it wouldn't
> make a difference. And if someone messes up their code by using tabs
> to align all their comments, reject that code at code review time.
> This ain't rocket science.

That *could* be the situation. However, it is trumped by an older
convention whereby the indentation levels go as follows:

   0:
   1: SPC SPC
   2: SPC SPC SPC SPC
   3: SPC SPC SPC SPC SPC SPC
   4: TAB
   5: TAB SPC SPC
   6: TAB SPC SPC SPC SPC
   7: TAB SPC SPC SPC SPC SPC SPC
   8: TAB TAB

That's how emacs indents source code files out of the box, BTW.

Moreover:

   SPC TAB = TAB
   SPC SPC SPC SPC SPC SPC SPC SPC = TAB

etc.

This older convention is honored by Python2 as well.

This older convention has been honored by many operating systems (at
least UNIX, CP/M and MS-DOS).

If I had to choose between your scheme and the older scheme, I'd choose
the older one.

Instead, I have chosen to banish HT as an unnecessary distraction.

Your scheme also is ad hoc in that it doesn't follow its logic to other
ASCII control characters. Why not use VT to separate methods? Why not
use US to separate operators from operands? Why not use RS to separate
the operands of optional arguments? Why not use GS to separate logical
blocks of code? After all, those schemes would allow people to
personalize the visual representation of more aspects of the source
code.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Chris Angelico]

On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
>
> Chris Angelico :
>
> > Tabs for indentation have semantic meaning. Top-level has zero tabs.
> > One indentation level is represented by one tab. Two indentation
> > levels? Two tabs. It's about as perfect a representation as you could
> > hope for. If you like your indentation levels to be as wide as four
> > spaces, you can have that. I could have them at eight, and it wouldn't
> > make a difference. And if someone messes up their code by using tabs
> > to align all their comments, reject that code at code review time.
> > This ain't rocket science.
>
> That *could* be the situation. However, it is trumped by an older
> convention whereby the indentation levels go as follows:
>
>0:
>1: SPC SPC
>2: SPC SPC SPC SPC
>3: SPC SPC SPC SPC SPC SPC
>4: TAB
>5: TAB SPC SPC
>6: TAB SPC SPC SPC SPC
>7: TAB SPC SPC SPC SPC SPC SPC
>8: TAB TAB

I've literally NEVER come across this as a convention. Not a single
file that I have ever worked with has used it. Where is this
convention from?

> Your scheme also is ad hoc in that it doesn't follow its logic to other
> ASCII control characters. Why not use VT to separate methods? Why not
> use US to separate operators from operands? Why not use RS to separate
> the operands of optional arguments? Why not use GS to separate logical
> blocks of code? After all, those schemes would allow people to
> personalize the visual representation of more aspects of the source
> code.

You're most welcome to use VT between methods. Not sure what you mean
by US, RS, and GS, but if they count as whitespace, you are absolutely
welcome to use them. I don't see why you have to use ALL of them if
you use any, but hey, if you want to, nobody's stopping you. What's
the issue here?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Peter J. Holzer]

On 2018-10-15 09:06:11 +1100, Chris Angelico wrote:
> On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
> > Chris Angelico :
> > > Tabs for indentation have semantic meaning. Top-level has zero tabs.
> > > One indentation level is represented by one tab. Two indentation
> > > levels? Two tabs. It's about as perfect a representation as you could
> > > hope for.
> >
> > That *could* be the situation. However, it is trumped by an older
> > convention whereby the indentation levels go as follows:
> >
> >0:
> >1: SPC SPC
> >2: SPC SPC SPC SPC
> >3: SPC SPC SPC SPC SPC SPC
> >4: TAB
> >5: TAB SPC SPC
> >6: TAB SPC SPC SPC SPC
> >7: TAB SPC SPC SPC SPC SPC SPC
> >8: TAB TAB

That's not using tabs for indentation, that's using tabs for compressing
spaces (somebody already mentioned that in this thread).


> I've literally NEVER come across this as a convention. Not a single
> file that I have ever worked with has used it. Where is this
> convention from?

It's something vi does by default, and apparently emacs as well.
In the 1970's saving space by replacing sequences of 8 spaces
with tabs seemed lika a good idea.

There are workarounds in vi(m), but I'm not sure if you can get rid of
that behaviour completely. I'm sure it is possible in emacs.

> > Your scheme also is ad hoc in that it doesn't follow its logic to other
> > ASCII control characters. Why not use VT to separate methods? Why not
> > use US to separate operators from operands? Why not use RS to separate
> > the operands of optional arguments? Why not use GS to separate logical
> > blocks of code? After all, those schemes would allow people to
> > personalize the visual representation of more aspects of the source
> > code.
> 
> You're most welcome to use VT between methods.

I sometimes use FF so separate sections of code in longer files. Had to
stop that in Django projects because it messes up the stack traces.

> Not sure what you mean by US, RS, and GS,

Unit separator, record separator, group separator (and FS is file
separator). I think they were intended for a CSV-like file format, but I
have never seen them in use (outside of my own projects).

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Cameron Simpson]

On 15Oct2018 00:33, Peter J. Holzer  wrote:

On 2018-10-15 09:06:11 +1100, Chris Angelico wrote:

On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
> Chris Angelico :
> > Tabs for indentation have semantic meaning. Top-level has zero tabs.
> > One indentation level is represented by one tab. Two indentation
> > levels? Two tabs. It's about as perfect a representation as you could
> > hope for.
>
> That *could* be the situation. However, it is trumped by an older
> convention whereby the indentation levels go as follows:
>
>0:
>1: SPC SPC
>2: SPC SPC SPC SPC
>3: SPC SPC SPC SPC SPC SPC
>4: TAB
>5: TAB SPC SPC
>6: TAB SPC SPC SPC SPC
>7: TAB SPC SPC SPC SPC SPC SPC
>8: TAB TAB


That's not using tabs for indentation, that's using tabs for compressing
spaces (somebody already mentioned that in this thread).



I've literally NEVER come across this as a convention. Not a single
file that I have ever worked with has used it. Where is this
convention from?


It's something vi does by default, and apparently emacs as well.
In the 1970's saving space by replacing sequences of 8 spaces
with tabs seemed lika a good idea.

There are workarounds in vi(m), but I'm not sure if you can get rid of
that behaviour completely. I'm sure it is possible in emacs.


I'm a "just use spaces" guy. I use the tab _key_ as a shortcut to do a 
bunch of spaces.


My vim setup has this:

 set expandtab

which turns them into spaces.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Alan Bawden]

Chris Angelico  writes:
> On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
> > Chris Angelico :
...
> > That *could* be the situation. However, it is trumped by an older
> > convention whereby the indentation levels go as follows:
> >
> >0:
> >1: SPC SPC
> >2: SPC SPC SPC SPC
> >3: SPC SPC SPC SPC SPC SPC
> >4: TAB
> >5: TAB SPC SPC
> >6: TAB SPC SPC SPC SPC
> >7: TAB SPC SPC SPC SPC SPC SPC
> >8: TAB TAB
> 
> I've literally NEVER come across this as a convention. Not a single
> file that I have ever worked with has used it. Where is this
> convention from?

I just picked a C source code file AT RANDOM from the FreeBSD source tree
on the machine I'm using to compose this message
(/usr/src/gnu/usr.bin/man/man/glob.c), and I find that, as I expected, it
uses exactly that convention.  And in that file, the comments don't line up
as the author clearly intended unless the tab stops are set every 8
columns.

In my experience this is a very common way to assume that tabs will be
interpreted.  Virtually every source-code file I have encountered since the
mid 1970s (for any programming language or operating system) has assumed
either this convention or, slightly less often, its 4-column variant.

It's surprising that you've never encountered it.

-- 
Alan Bawden
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: socket: Too many open files

[Cameron Simpson]

On 14Oct2018 20:24, Shakti Kumar  wrote:

On 13Oct2018 14:10, Shakti Kumar  wrote:

I’m running a script which basically does a traceroute to the list of
hosts
provided, and then pulls up some info by logging in to gateways in the

path.

I am running this script for a list of almost 40k hosts in our data

centers.

Also, I am using commands module to get the traceroute output.

out = commands.getstatusoutput('traceroute ' + ip)

However I observe that this particular line is failing with socket error
after I reach some 5k to 6k hosts.

[...]

In fact, given that it is file descriptors, maybe sockets are not what
is leaking?



From another terminal, see what your Python programme has open when this
happens with "lsof -n -p pid-of-python-programme". Maybe the leaks are
pipes, or connections from your "logging in to gateways in the path"
code. It may be as simple as you not closing files or connections.


Thanks Cameron, I still cant get over the fact that you were able to pin
point the issue even without looking at my code XD


Well it seemed likely that traceroute itself was not the cause because 
as you expected, when the command terminates its resources should clear 
up. That is one of the nice things about external executables - the OS 
tidies up their leaks, if any. (TCP sockets tend to hand around for a 
while to catch stray resent packets, but traceroute doesn't use TCP.)



Indeed when I started looking for sockets, I realised I was not closing
connections to ACI hosts in our datacentres, and the error was starting to
pop up at around 2900 to 3k TCP connections open to the hosts. XD


I think the takea away from my post, if any, is the usefulness of some 
external commands for inspecting behaviour if a problem seems 
intractable by inspection (eg "in Python" debugging, including prints 
etc).


Tools like strace, netstat and lsof are really good for seeing what the 
program is doing/leaking/misusing at an OS level. Even for opaque things 
like third party Java programmes, etc.


In your particular case, you're out of sockets (or possibly file 
desciptors). So use netstat to inspect the open sockets (and on Linux, 
"the open sockets for a particular PID" is an answerable question).  
Also, lsof will show your programme's open files, including the sockets.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Chris Angelico]

On Mon, Oct 15, 2018 at 9:56 AM Alan Bawden  wrote:
> In my experience this is a very common way to assume that tabs will be
> interpreted.  Virtually every source-code file I have encountered since the
> mid 1970s (for any programming language or operating system) has assumed
> either this convention or, slightly less often, its 4-column variant.
>
> It's surprising that you've never encountered it.

I've seen the four-column variant, but never the two. Maybe I just
move in different circles. In any case, I wouldn't say that "two space
indents, collapsed to a tab after eight" is somehow a universal
convention any more than four-space with or without collapsing.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Alan Bawden]

Chris Angelico  writes:
> On Mon, Oct 15, 2018 at 9:56 AM Alan Bawden  wrote:
> > In my experience this is a very common way to assume that tabs will be
> > interpreted.  Virtually every source-code file I have encountered since the
> > mid 1970s (for any programming language or operating system) has assumed
> > either this convention or, slightly less often, its 4-column variant.
> >
> > It's surprising that you've never encountered it.
> 
> I've seen the four-column variant, but never the two. Maybe I just
> move in different circles. In any case, I wouldn't say that "two space
> indents, collapsed to a tab after eight" is somehow a universal
> convention any more than four-space with or without collapsing.

I think we're talking past each other somehow here.  I described the common
8-column interpretation, and the less common 4-column interpretation.  I
did not mention, nor do I ever remember encountering in the wild, the
2-column variation.  (I _have_ seen the 10-column variation used -- it was
the standard on Multics.)

The ANSI standard for ASCII only describes the tab character as follows:

   7.21 HT (HORIZONTAL TABULATION). A format effector that causes the
   active position to advance to the next predetermined character position.

This says nothing about where those "predetermined character positions"
happen to be.  They could be set at columns 5, 17, 23, 99 and 100, or they
could be set every N columns for some N, or wherever you want, it's up to
you.  (Note that this is exactly the way mechanical typewriters used to
work: "tab stops" were originally physical sliders that you would position
manually, and then when you pressed the "tab" key, a spring would pull the
carriage holding the paper to the left until it would be physically
_stopped_ by the tab stop.)

Given that the ANSI standard is silent on where the tab stops should be set
for the HT character, we can only ask where they are set _in practice_,
based on looking at he contents of files and the behavior of various pieces
of software.  For example, in the Linux termios(3) manual page describes
one of the options you can set to control output to a terminal:

   TABDLY Horizontal tab delay mask.  Values are TAB0, TAB1, TAB2, TAB3 (or
  XTABS).  A value of TAB3, that is, XTABS, expands tabs to spaces
  (with tab stops every eight columns).

So if tabs are going to be converted to spaces on output, your only choice
is the every-8-columns interpretation.  (Interestingly, setting TABDLY to
TAB3 to convert tabs to spaces is part of POSIX, but the POSIX standard
does _not_ appear to specify the positions of the tab stops!)

The 8-column interpretation is also the default behavior in every text
editor I have ever used (except, as I noted above, on Multics!).

The 8-column interpretation also seems most common in source code files,
although 4-column files do show up occasionally.

So when you say:

   I've literally NEVER come across this as a convention.  Not a single
   file that I have ever worked with has used it.  Where is this convention
   from?

I feel that there _must_ be some misunderstanding here.  Maybe you
misinterpreted Marko's description of how 8-column tabs are used to achieve
2-columns-per-level indentation.  Or maybe I'm misunderstanding what you
mean by "convention".  Or maybe one of us just beamed in from parallel
universe...

-- 
Alan Bawden
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Chris Angelico]

On Mon, Oct 15, 2018 at 2:51 PM Alan Bawden  wrote:
>
> Chris Angelico  writes:
> > On Mon, Oct 15, 2018 at 9:56 AM Alan Bawden  wrote:
> > > In my experience this is a very common way to assume that tabs will be
> > > interpreted.  Virtually every source-code file I have encountered since 
> > > the
> > > mid 1970s (for any programming language or operating system) has assumed
> > > either this convention or, slightly less often, its 4-column variant.
> > >
> > > It's surprising that you've never encountered it.
> >
> > I've seen the four-column variant, but never the two. Maybe I just
> > move in different circles. In any case, I wouldn't say that "two space
> > indents, collapsed to a tab after eight" is somehow a universal
> > convention any more than four-space with or without collapsing.
>
> I think we're talking past each other somehow here.  I described the common
> 8-column interpretation, and the less common 4-column interpretation.  I
> did not mention, nor do I ever remember encountering in the wild, the
> 2-column variation.  (I _have_ seen the 10-column variation used -- it was
> the standard on Multics.)
> [chomp details]

I believe we are in agreement here - that it is common for a tab to be
interpreted as equivalent to eight spaces, but also that this is
definitely not the definition of the character. The convention that
I'm saying I have never seen is this:

On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
> However, it is trumped by an older
> convention whereby the indentation levels go as follows:
>
>0:
>1: SPC SPC
>2: SPC SPC SPC SPC
>3: SPC SPC SPC SPC SPC SPC
>4: TAB
>5: TAB SPC SPC
>6: TAB SPC SPC SPC SPC
>7: TAB SPC SPC SPC SPC SPC SPC
>8: TAB TAB

Specifically that two-space indents and tab-collapsing are a
*convention*. I have never seen this used anywhere, much less seen it
commonly enough to call it a convention.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Marko Rauhamaa]

Chris Angelico :
> I'm saying I have never seen is this:
>
> On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
>> However, it is trumped by an older
>> convention whereby the indentation levels go as follows:
>>
>>0:
>>1: SPC SPC
>>2: SPC SPC SPC SPC
>>3: SPC SPC SPC SPC SPC SPC
>>4: TAB
>>5: TAB SPC SPC
>>6: TAB SPC SPC SPC SPC
>>7: TAB SPC SPC SPC SPC SPC SPC
>>8: TAB TAB
>
> Specifically that two-space indents and tab-collapsing are a
> *convention*. I have never seen this used anywhere, much less seen it
> commonly enough to call it a convention.

The two-space indentation is the out-of-the-box default for emacs.
However, the tab collapsing principle is a universal default. If you go
against it, you will have to educate more tools than your editor. For
example, try running this Python snippet (in REPL or as a program):

for i in range(32):
print("x{}\ty".format(" " * i))


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Chris Angelico]

On Mon, Oct 15, 2018 at 3:51 PM Marko Rauhamaa  wrote:
> The two-space indentation is the out-of-the-box default for emacs.
> However, the tab collapsing principle is a universal default. If you go
> against it, you will have to educate more tools than your editor. For
> example, try running this Python snippet (in REPL or as a program):
>
> for i in range(32):
> print("x{}\ty".format(" " * i))
>

I don't understand your point here. It prints a letter, then some
spaces, then a tab, then another letter. On my terminal, that displays
the tab by advancing to the next tab position. If I highlight to
select, it's obvious that the spaces have not been collapsed or
converted in any way; it is indeed printing that many spaces, then a
tab. Universal default? Not very.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ESR "Waning of Python" post

[dieter]

Marko Rauhamaa  writes:
> dieter :
> ...
>> Definitely. The application concerned was a long running web application;
>> caching was an important feature to speed up its typical use cases.
>
> As an optimization technique, I suggest turning the cache into a "binary
> blob" opaque to GC, or using some external component like SQLite.

This was a Python application and as such, it was primarily working with
Python objects. And it was a complex application heavily depending
on subframeworks, many of them internally using caching to speed
things up, the details hidden from the application.
Redesigning the application to use an alternative caching was
out of question.


> Keeping the number of long-term objects low is key.

Right, if I need near realtime behaviour and must live
with [C]Python's garbage collector.

But, a web application does usually not need near realtime behaviour.
An occasional (maybe once in a few days) garbage collection and
associated reduced response time is acceptable.
A problem only arises if a badly designed component produces
quite frequently hundreds of thousands of temporary objects
likely triggering (frequent) garbage collections.


> Note that Python creates a temporary object every time you invoke a
> method. CPython removes them quickly through reference counting, but
> other Python implementations just let GC deal with them, and that's
> generally ok.

The initial point has been that you must carefully look at the context
for which you design a solution and choose appropriately (among
other the implementation language).
In my case, the web application framework was fixed ("Zope")
and therefore the language ("Python") and its implementation ("CPython").
"Normal" temporary objects did not pose a problem (due to reference
counting); only the mass creation of temporary objects can
be problematic (as GC is triggered before the temporary objects
are released again (due to reference counting).

>
>
> Marko

-- 
https://mail.python.org/mailman/listinfo/python-list