Re: Who are the "spacists"?

[Marko Rauhamaa]

Steve D'Aprano :

> 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?

Pretty much. Try printing out your program with lpr, or sending it to
the terminal with cat, or opening it with with Firefox.


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

Re: Who are the "spacists"?

[Chris Angelico]

On Mon, Mar 20, 2017 at 6:01 PM, Marko Rauhamaa  wrote:
> Steve D'Aprano :
>
>> 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?
>
> Pretty much. Try printing out your program with lpr, or sending it to
> the terminal with cat, or opening it with with Firefox.

I don't use paper, but I tried cat and Firefox. In each case, the tab
characters showed precisely as they should: as indentation. Was it the
exact same amount of indentation that showed when I originally wrote
the text in my editor? Was it displayed in the same font as my text
editor uses? Was the window the same size as that of my text editor?
Was the text colour the same everywhere? And do any of these questions
even matter?

Semantically, indentation is indentation. Obviously there are
ridiculous extremes (a tab character probably shouldn't indent by just
one pixel, nor should it normally indent by the entire width of a
line), but even those should be under the control of the viewer, not
the author. I prefer to use tabs in my code precisely *because* they
are not defined in a concrete way. The only thing I demand of the
display is that a sequence of N tabs be narrower than a sequence of
N+1 tabs.

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

Re: cryptography default_backend is "hazmat"?

[Ian Pilcher]

On 03/19/2017 05:46 PM, Paul Moore wrote:

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.


Actually, even loading an X.509 certificate from a PEM file requires
a backend, which means delving into the "hazmat" area.

I'm not saying that some crypto functions require careful handling; they
obviously do. But is default_backend one of them?

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


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

Re: Who are the "spacists"?

[Marko Rauhamaa]

Chris Angelico :

> On Mon, Mar 20, 2017 at 6:01 PM, Marko Rauhamaa  wrote:
>> Pretty much. Try printing out your program with lpr, or sending it to
>> the terminal with cat, or opening it with with Firefox.
>
> I don't use paper, but I tried cat and Firefox. In each case, the tab
> characters showed precisely as they should: as indentation. Was it the
> exact same amount of indentation that showed when I originally wrote
> the text in my editor? Was it displayed in the same font as my text
> editor uses? Was the window the same size as that of my text editor?
> Was the text colour the same everywhere? And do any of these questions
> even matter?

Those questions do matter when you mix whitespace and tabs, as well as
in cases like these:

call_some_function(1,
   2,
   3)

The tools I mentioned honor the traditional tab stop columns:

1, 9, 17, 25, 33, 41, 49, 57, 65, 73

> Semantically, indentation is indentation.

The presence of a HT code point in a plain text file is not a semantic
marker for indentation. It is a silly, traditional compression scheme
for whitespace.

> I prefer to use tabs in my code precisely *because* they are not
> defined in a concrete way.

If you ever had to review C source code pull requests where tabs and
spaces alternate randomly...


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

Re: Who are the "spacists"?

[Chris Angelico]

On Mon, Mar 20, 2017 at 6:37 PM, Marko Rauhamaa  wrote:
>> I don't use paper, but I tried cat and Firefox. In each case, the tab
>> characters showed precisely as they should: as indentation. Was it the
>> exact same amount of indentation that showed when I originally wrote
>> the text in my editor? Was it displayed in the same font as my text
>> editor uses? Was the window the same size as that of my text editor?
>> Was the text colour the same everywhere? And do any of these questions
>> even matter?
>
> Those questions do matter when you mix whitespace and tabs, as well as
> in cases like these:
>
> call_some_function(1,
>2,
>3)
>
> The tools I mentioned honor the traditional tab stop columns:
>
> 1, 9, 17, 25, 33, 41, 49, 57, 65, 73

(Point of clarity: "whitespace" is a general term that covers U+0020
SPACE, U+0009 CHARACTER TABULATION, U+000A LINE FEED, U+2008
PUNCTUATION SPACE, and others. You're talking about mixing *spaces*
and tabs.)

That means that you were depending, in your source file, on something
that isn't actually part of the character's definition. You're
depending on "horizontal tab" meaning those exact tab stops. If you
want those semantics, you should use spaces - or better still, *change
your needs* and don't align things like that. In far too many fonts,
this simply won't work. (It was only from context that I figured out
that that's what you were even aiming for. It didn't work in my
email.)

>> Semantically, indentation is indentation.
>
> The presence of a HT code point in a plain text file is not a semantic
> marker for indentation. It is a silly, traditional compression scheme
> for whitespace.

Only if you truly expect and assume that. Can you show me a standards
document that says "the meaning of this byte/character value is this
sequence of this other byte/character"?

>> I prefer to use tabs in my code precisely *because* they are not
>> defined in a concrete way.
>
> If you ever had to review C source code pull requests where tabs and
> spaces alternate randomly...

Yes, and if you've ever had to review source code pull requests where
the letters "q" and "e" were used interchangeably, you'd also be
appalled. The different kinds of whitespace have different semantic
meanings, and while I'm sympathetic to the desire to stick to ASCII
where possible (resulting in a pair of newlines often being used to
represent a paragraph, where semantically U+2029 PARAGRAPH SEPARATOR
would be more appropriate), I believe that the meanings of different
characters should be respected. You wouldn't separate words in a
sentence with form-feeds; nor should you mix tabulation and space
characters to create indentation.

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

Python BBS (and more)

[Avon]

Hi all.

Just a FYI that a new Wiki has been started at wiki.bbs.geek.nz which aims to
provide helpful information to bulletin board system (BBS) developers and
users.

It's a work in progress with a growing number of contributors that include
tutorials related to coding a BBS using Python and another using Crystal.

There are also links to other open source and closed source BBS platforms
under active development in 2017

The FTN style network that is sponsoring these efforts and being used as a
place for online discussions (echoarea FSX_BBS) is called fsxNet. If you
would like to know more visit bbs.geek.nz or grab an infopack at
bbs.geek.nz/fsxnet.zip

Best, Paul

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

Re: Who are the "spacists"?

[Marko Rauhamaa]

Chris Angelico :

> On Mon, Mar 20, 2017 at 6:37 PM, Marko Rauhamaa  wrote:
>> The tools I mentioned honor the traditional tab stop columns:
>>
>> 1, 9, 17, 25, 33, 41, 49, 57, 65, 73
>
> (Point of clarity: "whitespace" is a general term that covers U+0020
> SPACE, U+0009 CHARACTER TABULATION, U+000A LINE FEED, U+2008
> PUNCTUATION SPACE, and others. You're talking about mixing *spaces*
> and tabs.)
>
> That means that you were depending, in your source file, on something
> that isn't actually part of the character's definition.

Those tab stops are a 40-year-old de-facto UNIX standard.

> You're depending on "horizontal tab" meaning those exact tab stops.

Not me. All terminal emulators, editors, text utils etc honor the
convention out of the box. No wonder then that C source code files have
consecutive lines indented randomly:

   HT
   SPC HT
   SPC SPC SPC SPC HT

etc. The tools show no visible difference between those variants, so you
can't blame the developers for being inconsistent.

> If you want those semantics, you should use spaces -

That is precisely what we have done: HT is banished (except in
Makefiles, but we have banished Makefiles as well...).

> or better still, *change your needs* and don't align things like that.
> In far too many fonts, this simply won't work.

You must use fixed-width fonts even in the absense of HT's. Try RFC 793,
for example:

   TCP Header Format

0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Source Port  |   Destination Port|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sequence Number|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Acknowledgment Number  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |   |U|A|P|R|S|F|   |
   | Offset| Reserved  |R|C|S|S|Y|I|Window |
   |   |   |G|K|H|T|N|N|   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Checksum| Urgent Pointer|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Options|Padding|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | data  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Those kinds of ASCII graphics diagrams are commonplace in source code
comments.

> (It was only from context that I figured out that that's what you were
> even aiming for. It didn't work in my email.)

When participating in technical discussions, I strongly recommend using
a fixed-width font. For example:

   =  =  ===
 A  BA and B
   =  =  ===
   False  False  False
   True   False  False
   False  True   False
   True   True   True
   =  =  ===

   https://www.python.org/dev/peps/pep-0012/>

>> The presence of a HT code point in a plain text file is not a
>> semantic marker for indentation. It is a silly, traditional
>> compression scheme for whitespace.
>
> Only if you truly expect and assume that. Can you show me a standards
> document that says "the meaning of this byte/character value is this
> sequence of this other byte/character"?

I already mentioned three examples: lpr, cat on a terminal and Firefox.
Ultimately, it's the terminals that dictate the de-facto standard.

I bet some terminal emulators support ANSI escape sequences to set the
tab stops to arbitrary columns, but nobody uses that type-writer-era
mechanism.

>> If you ever had to review C source code pull requests where tabs and
>> spaces alternate randomly...
>
> Yes, and if you've ever had to review source code pull requests where
> the letters "q" and "e" were used interchangeably, you'd also be
> appalled.

Huh? I'm talking about a real issue. I'm surprised you haven't run into
it.

> The different kinds of whitespace have different semantic meanings,

Only in your head (and Makefiles).


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

Re: Who are the "spacists"?

[Chris Angelico]

On Mon, Mar 20, 2017 at 8:56 PM, Marko Rauhamaa  wrote:
> All terminal emulators, editors, text utils etc honor the
> convention out of the box. No wonder then that C source code files have
> consecutive lines indented randomly:
>
>HT
>SPC HT
>SPC SPC SPC SPC HT
>
> etc. The tools show no visible difference between those variants, so you
> can't blame the developers for being inconsistent.

Actually you can, for the same reason that you expect programmers to
use ASCII Latin to write language keywords, not other symbols that
happen to look identical.

>> If you want those semantics, you should use spaces -
>
> That is precisely what we have done: HT is banished (except in
> Makefiles, but we have banished Makefiles as well...).
>
>> or better still, *change your needs* and don't align things like that.
>> In far too many fonts, this simply won't work.
>
> You must use fixed-width fonts even in the absense of HT's.
> [chomp examples]

Yes, there are good reasons for using monospaced fonts for certain
types of documents. But if those documents have been created
correctly, they won't be mixing tabs and spaces to achieve that
alignment - they'll be using spaces exclusively.

>>> The presence of a HT code point in a plain text file is not a
>>> semantic marker for indentation. It is a silly, traditional
>>> compression scheme for whitespace.
>>
>> Only if you truly expect and assume that. Can you show me a standards
>> document that says "the meaning of this byte/character value is this
>> sequence of this other byte/character"?
>
> I already mentioned three examples: lpr, cat on a terminal and Firefox.
> Ultimately, it's the terminals that dictate the de-facto standard.

Do they actually document that its meaning is strictly as you
describe? On all of my terminals, a tab is *NOT* the same thing as X
spaces - for example, highlighting with the mouse will grab the entire
tab as a single character, and will copy it to the clipboard as a
character. Also, check out 'man tabs'. It's trivially easy to tell the
terminal to use a different set of tab stops, and catting a file will
look different. Notice that I didn't say "reconfigure cat". It's not
cat that does this - it's only the terminal, and I suspect that every
modern terminal on every POSIX system supports it (since the 'tabs'
command is itself part of POSIX). What 'lpr' does with tabs I don't
know, because paper is an archaic data transmission format that I use
only when absolutely necessary (such as when sending information off
to the gummint). Firefox... what's the betting that it can be
configured too, maybe with CSS?

> I bet some terminal emulators support ANSI escape sequences to set the
> tab stops to arbitrary columns, but nobody uses that type-writer-era
> mechanism.

Probably not. Most people would use the tabs(1) command instead.

>>> If you ever had to review C source code pull requests where tabs and
>>> spaces alternate randomly...
>>
>> Yes, and if you've ever had to review source code pull requests where
>> the letters "q" and "e" were used interchangeably, you'd also be
>> appalled.
>
> Huh? I'm talking about a real issue. I'm surprised you haven't run into
> it.

Maybe I have, and just rejected the PR out of hand. It certainly isn't
something that I am forced to wrestle with. Every PR that I have
accepted has been internally consistent (either all tabs or all
spaces).

>> The different kinds of whitespace have different semantic meanings,
>
> Only in your head (and Makefiles).

And in the Unicode specifications, and in a lot of other people's
heads. But you're welcome to reject all that too.

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

EuroPython 2017: We have liftoff!

[M.-A. Lemburg]

We are excited to announce the launch of the EuroPython 2017 website:


 *** http://ep2017.europython.eu/ ***


  The EuroPython conference will take place in sunny
 Rimini, Italy, this year, from July 9 - 16.


EuroPython 2017 - The European Python Conference


Here’s an overview of what you can expect in Rimini:

We will start with a Beginner’s Day workshop and a Django Girls
workshop on Sunday, July 9.

The main 5 conference days follow, packed with keynotes, talks,
training sessions, help desks, interactive sessions, panels and
poster sessions.

A complete PyData EuroPython is included as well.

The two weekend days after the conference, July 15 and 16, are
reserved for sprints.

Overall, we will again have 8 days worth of great Python content,
arranged in over 200 sessions, waiting for you.

In short:

 * Sunday, July 9: Beginners’ Day Workshop and other workshops

 * Monday - Friday, July 10-14: Conference talks, keynotes, training

 * Saturday, Sunday, July 15-16: Sprints

Meet our sponsors
-

All this would not be possible without the generous help of our launch
sponsors:

 * Intel
 * CFM
 * Facebook
 * Microsoft
 * numberly
 * criteo labs
 * JetBrains
 * Kiwi.com
 * yelp
 * 2ndQuadrant
 * TrustYou
 * demonware
 * Riverbank
 * Plone Foundation

In the coming days, we will announce the start of the Call for
Proposals and Early Bird Ticket sales. Please watch our EuroPython
blog for updates.

 https://ep2017.europython.eu/social-media/

Enjoy,
–
EuroPython 2017 Team
http://ep2017.europython.eu/
http://www.europython-society.org/


PS: Please forward or retweet to help us reach all interested parties:
https://twitter.com/europython/status/843769909796655104
Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

How to package my project and make it ready to be installed by using pip

[Daiyue Weng]

Hi, I using Python 3.5.2 on Linux Mint 18.1, and I am wondering how to
package my PyCharm Python project as a module so that it can installed by
someone else by using pip. Like what tools and script I need to use or
write in order to do that.

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

Re: How to package my project and make it ready to be installed by using pip

[Glenn Hutchings]

On Monday, 20 March 2017 11:36:34 UTC, Daiyue Weng  wrote:
> Hi, I using Python 3.5.2 on Linux Mint 18.1, and I am wondering how to
> package my PyCharm Python project as a module so that it can installed by
> someone else by using pip. Like what tools and script I need to use or
> write in order to do that.

A good place to start is https://packaging.python.org.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Chris Angelico :

> On Mon, Mar 20, 2017 at 8:56 PM, Marko Rauhamaa  wrote:
>> I bet some terminal emulators support ANSI escape sequences to set
>> the tab stops to arbitrary columns, but nobody uses that
>> type-writer-era mechanism.
>
> Probably not. Most people would use the tabs(1) command instead.

>From "man tabs":

   Use "-8" to set tabs to the standard interval.

I'd argue most people never touch the standard interval.

>>> The different kinds of whitespace have different semantic meanings,
>>
>> Only in your head (and Makefiles).
>
> And in the Unicode specifications,

Unicode was 25 years late to the game, but please point me to the
paragraph anyway.


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

Re: Who are the "spacists"?

[Chris Angelico]

On Tue, Mar 21, 2017 at 12:30 AM, Marko Rauhamaa  wrote:
>> And in the Unicode specifications,
>
> Unicode was 25 years late to the game, but please point me to the
> paragraph anyway.

3.3, D3 Character semantics: The semantics of a character are
determined by its identity, normative properties, and behavior.

That's the best I can find for you. The best statement that says "hey
you idiot, a character's name indicates the intended semantics of that
character". If U+0009's name were "SHORTER ENCODED FORM FOR SEQUENCE
OF SPACES", then I might be prepared to believe you. But it isn't.
It's "CHARACTER TABULATION". Does the specification really need to say
"don't be a fool"?

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

Re: Who are the "spacists"?

[Steve D'Aprano]

On Tue, 21 Mar 2017 12:30 am, Marko Rauhamaa wrote:

> Unicode was 25 years late to the game

I don't understand that comment. Are you suggesting that the oldest
convention wins? The Unix 8-column convention is older than Unicode, so it
wins?

Well... in that case, there are tab conventions that pre-date Unix, e.g.
those used by COBOL. The tabs command offers them as pre-defined standards.
From the man page:

   -c 1,8,12,16,20,55
  COBOL, normal format.

But wait... before there was COBOL, there were *typewriters*. Its been many
years since I've had my hands on a manual typewriter, but if I remember
correctly the standard default tab setting was 1 inch.

So there you go. Unix was 50+ years late to the game.




-- 
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"?

[BartC]

On 20/03/2017 08:15, Chris Angelico wrote:

On Mon, Mar 20, 2017 at 6:37 PM, Marko Rauhamaa  wrote:



The tools I mentioned honor the traditional tab stop columns:

1, 9, 17, 25, 33, 41, 49, 57, 65, 73



That means that you were depending, in your source file, on something
that isn't actually part of the character's definition. You're
depending on "horizontal tab" meaning those exact tab stops. If you
want those semantics, you should use spaces


There are effectively two versions of the text: the slightly higher 
level, or 'marked up' version containing these special controls, and the 
'rendered' version you see displayed on the screen.


You're suggesting doing away with the controls, working only with the 
rendered snapshot version. Which means instead of pressing Backspace 
once to delete a tab, you might need to press it 8 times, or 1 to 8 
times if not at the start.


This is little different to inserting hard newlines at the end of each 
visible line of a paragraph, to ensure that it is shown how you want it 
and isn't 'reflowed' depending on the width of someone's display.


Which work great - until you have to edit the text with those newlines 
present, which can be a lot of work.


So really you want to keep and work with the original version, not the 
rendered one.


In the case of tabs, it might be possible to take the rendered text (I 
call it 'flat' text because the tabs have been flattened out) and 
reconstruct the tabs, but there are some problems (are those 8 spaces 
one tab, or two or four, or were they just 8 spaces?).


It might be a little easier if the text represented, say, Python source 
code.


But it would be better IMO if tabs were used, with some scheme for 
suggesting the tab width (or set of tab stops) that is recommended (eg. 
a comment at the top).


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

Re: Who are the "spacists"?

[Chris Angelico]

On Tue, Mar 21, 2017 at 1:24 AM, BartC  wrote:
> But it would be better IMO if tabs were used, with some scheme for
> suggesting the tab width (or set of tab stops) that is recommended (eg. a
> comment at the top).

If you absolutely have to, then sure, put a directive in some
machine-readable way at the top or bottom of the file. It's like the
coding cookie that Python follows - some editors also respect it. But
I would prefer to just use tabs *without* suggesting a width, because
each one represents *one indent*. Not a number of spaces. One
indentation level.

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

How to search out all Zip codes and replace with the first 2 digits, in a Pandas dataframe, with the use of regex?

[David Shi via Python-list]

Hi, there,
Can anyone help?
How to search out all Zip codes and replace with the first 2 digits, in a 
Pandas dataframe, with the use of regex?

For instance, a ZIP code 33132 was found and replaced with 33.
Looking forward to hearing from you.
Regards.
David
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[BartC]

On 20/03/2017 14:32, Chris Angelico wrote:

On Tue, Mar 21, 2017 at 1:24 AM, BartC  wrote:

But it would be better IMO if tabs were used, with some scheme for
suggesting the tab width (or set of tab stops) that is recommended (eg. a
comment at the top).


If you absolutely have to, then sure, put a directive in some
machine-readable way at the top or bottom of the file. It's like the
coding cookie that Python follows - some editors also respect it. But
I would prefer to just use tabs *without* suggesting a width, because
each one represents *one indent*. Not a number of spaces. One
indentation level.


For leading tabs at the start of a new statement that wouldn't be a 
problem. Changing the tab width shown just spreads out statements more, 
or less, horizontally.


It works - there is no jarring misalignment - because each tab 
corresponds to the same N spaces, whatever N happens to be.


But tabs are also used after statements, before comments for example, or 
to line up elements in tables. Then it doesn't work, because tabs may 
represent 1 to N spaces:


Using N=4, with 1 tab before each number:

(one,   1), #comment 1
(two,   2), #comment 2
(three, 3), #comment 3

Displayed using N=3:

   (one, 1), #comment 1
   (two, 2), #comment 2
   (three,  3), #comment 3

Displayed using N=6:

   (one, 1),   #comment 1
   (two, 2),   #comment 2
   (three, 3),   #comment 3

Even tabs at the start of a line are sometimes using to line things up 
with a previous line; here with N=4, and 5 tabs before B and C:


 longfunctionname (  A,  #comment 1
 B,  #comment 2
 C)  #comment 3

With N=2:

longfunctionname (  A,  #comment 1
  B,  #comment 2
  C)  #comment 3

With N=8:

longfunctionname (  A,  #comment 1
B,  #comment 2
C)  #comment 3


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

Re: Who are the "spacists"?

[Chris Angelico]

On Tue, Mar 21, 2017 at 2:19 AM, BartC  wrote:
> But tabs are also used after statements, before comments for example, or to
> line up elements in tables. Then it doesn't work, because tabs may represent
> 1 to N spaces:
>
> Using N=4, with 1 tab before each number:
>
> (one,   1), #comment 1
> (two,   2), #comment 2
> (three, 3), #comment 3
>
> Displayed using N=3:
>
>(one, 1), #comment 1
>(two, 2), #comment 2
>(three,  3), #comment 3
>
> Displayed using N=6:
>
>(one, 1),   #comment 1
>(two, 2),   #comment 2
>(three, 3),   #comment 3
>
> Even tabs at the start of a line are sometimes using to line things up with
> a previous line; here with N=4, and 5 tabs before B and C:
>
>  longfunctionname (  A,  #comment 1
>  B,  #comment 2
>  C)  #comment 3
>
> With N=2:
>
> longfunctionname (  A,  #comment 1
>   B,  #comment 2
>   C)  #comment 3
>
> With N=8:
>
> longfunctionname (  A,  #comment 1
> B,  #comment 2
> C)  #comment 3

My points here are the same as for the other examples:

1) Preferably, don't do it at all.
2) If you absolutely have to do it, then by definition you're counting
character slots, so use spaces, not tabs.

Note that PEP 8 specifically forbids one of these kinds of usages:

"""
More than one space around an assignment (or other) operator to align
it with another.

Yes:

x = 1
y = 2
long_variable = 3

No:

x = 1
y = 2
long_variable = 3
"""

The reasoning behind this also applies to most of the other forms:
you're fiddling with formatting in ways that have to be forever
fiddled with as you make edits.

Here's a suggestion: Use a single tab after a statement and before the
hash. Exactly one tab. Then configure your editor to right-align that.
If someone else's editor doesn't right-align, no big deal, and you'll
get some measure of alignment anyway (eg if tabs are every eight
spaces, it rounds the alignment off to the next eight-mark); it won't
hurt anything, as those of us who don't care about the alignment won't
be bothered anyway.

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

Re: Who are the "spacists"?

[Tobiah]

> 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 can't think of any classic Unix tool that behaves in a way that would support 
this
point of view.


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

Re: Who are the "spacists"?

[Random832]

On Sun, Mar 19, 2017, at 18:48, Mikhail V wrote:
> Sadly, many people believe that a code editor
> should be monospaced, but generally that does not
> have any sense.

It's also a bit self-reinforcing because there aren't many good coding
fonts that are proportional. And in fact there are issues for coding
usability in proportional fonts that aren't even present for monospaced
fonts. Confusables like lI1| O0 are only the beginning of the story. If
, and ' are only one pixel wide each, it's hard to tell which order they
are in. And in many proportional fonts it is difficult or impossible to
distinguish '' from ". Other issues also exist, such as """ having more
space between the ticks of a single character than between characters,
looking more like '""'. @ and % and sometimes # are too wide and too
short. Minus is too narrow, too thick, and too low owing to its design
as a hyphen (U+2212 is usually nicer, but not used in programming
languages). < and > are wide and low, which works great as relational
operators but makes them visually unpleasant as brackets - and >=
doesn't look nice either. {} are often too tall, too narrow, and a
little bit too curly.

So people try coding in the proportional fonts available on their
systems and rightly note how ugly it is.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to package my project and make it ready to be installed by using pip

[Daiyue Weng]

I have been Python Packaging User Guide ,
and I created a setup.py in my PyCharm project root,

from setuptools import setup, find_packages
from os import path

here = path.abspath(path.dirname(__file__))

packages = find_packages(exclude=['contrib', 'docs', 'tests*'])

setup(
name='lumar_stackdriver_logging',

description='A sample Python project',


author='project_dev',
author_email='pypa-...@googlegroups.com',


# Choose your license
license='GNU GPL',

# See https://pypi.python.org/pypi?%3Aaction=list_classifiers
classifiers=[
# How mature is this project? Common values are
#   3 - Alpha
#   4 - Beta
#   5 - Production/Stable
'Development Status :: 3 - Alpha',

# Indicate who your project is intended for
'Intended Audience :: Project Developers',
'Topic :: System :: Logging',

# Pick your license as you wish (should match "license" above)
'License :: OSI Approved :: GNU General Public License (GPL)',

# Specify the Python versions you support here. In particular, ensure
# that you indicate whether you support Python 2, Python 3 or both.
# 'Programming Language :: Python :: 3',
# 'Programming Language :: Python :: 3.2',
# 'Programming Language :: Python :: 3.3',
# 'Programming Language :: Python :: 3.4',
'Programming Language :: Python :: 3.5',
],

# What does your project relate to?
keywords='sample setuptools development',


# You can just specify the packages manually here if your project is
# simple. Or you can use find_packages().
packages=packages,
)


I uploaded/committed the project into a Git repo/BitBucket, what I
want is anyone who can access the repo, can deploy the project from
the repo to their machines using pip.

I am wondering how to achieve that?


Many thanks


On 20 March 2017 at 11:57, Daiyue Weng  wrote:

> thanks, i am reading it.
>
> On 20 March 2017 at 11:50, Glenn Hutchings  wrote:
>
>> On Monday, 20 March 2017 11:36:34 UTC, Daiyue Weng  wrote:
>> > Hi, I using Python 3.5.2 on Linux Mint 18.1, and I am wondering how to
>> > package my PyCharm Python project as a module so that it can installed
>> by
>> > someone else by using pip. Like what tools and script I need to use or
>> > write in order to do that.
>>
>> A good place to start is https://packaging.python.org.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

cross python version randomness

[Robin Becker]

Is there a way to get the same sequences of random numbers in python 2.7 and 
python >= 3.3?


I notice that this simple script produces different values in python 2.7 and 
>=3.3

C:\code\hg-repos\reportlab>cat s.py
import sys, random
print(sys.version)
random.seed(103)
for i in range(5):
print(i, random.randint(10,25))

C:\code\hg-repos\reportlab>\python27\python s.py
2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 64 bit (AMD64)]
0 25
1 17
2 21
3 21
4 13

C:\code\hg-repos\reportlab>\python33\python s.py
3.3.5 (v3.3.5:62cf4e77f785, Mar  9 2014, 10:35:05) [MSC v.1600 64 bit (AMD64)]
0 24
1 16
2 12
3 13
4 22

However, when I use random.random() all seems to be the same so this script
C:\code\hg-repos\reportlab>cat u.py
import sys, random
print(sys.version)
random.seed(103)
for i in range(5):
print(i, random.random())

seems to be fine


C:\code\hg-repos\reportlab>\python27\python u.py
2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 64 bit (AMD64)]
(0, 0.9790501200727744)
(1, 0.45629827629184827)
(2, 0.7188470341002364)
(3, 0.7348862425853395)
(4, 0.21490166849706338)

C:\code\hg-repos\reportlab>\python33\python u.py
3.3.5 (v3.3.5:62cf4e77f785, Mar  9 2014, 10:35:05) [MSC v.1600 64 bit (AMD64)]
0 0.9790501200727744
1 0.45629827629184827
2 0.7188470341002364
3 0.7348862425853395
4 0.21490166849706338

presumably randint is doing something different to get its values.
--
Robin Becker

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

relative paths connect using python

[Xristos Xristoou]

i have a little confused problem. i want to store some paths from images using 
python 2.7 in windows 10.
i have some relative path like this var1='C:/my/store/path' and in the final 
folder where in my example is the name 'path' inside that folder i have some 
images like this :
-path
   -myimage_1010_im.png
   -myimage_1010_im1.png
   -myimage_1010_im3.png
   -myimage_1020_im.png
   -myimage_1020_im1.png
can i connect my relative path like var1 with the images using only the number 
of the mid name of images and finaly i take the full original path like this 
var1='C:/my/store/path/myimage_1010_im.png' ?
i try something but not work 
import os
cwd = os.getcwd()
path = os.path.join(cwd, "my_file")
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[jladasky]

On Sunday, March 19, 2017 at 1:11:45 PM UTC-7, Mikhail V wrote:

> 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. 

This is a good example of exactly WHY I continue to write code using monospaced 
fonts, and spaces for indentation.  The results are unambiguous.  If I want 
vertical alignment between specific characters in different rows, I can have 
it.  I am not only interested in the indentation of the first character in a 
line of code.  Yes, sometimes I have to adjust the spacing manually, but I can 
live with that.

Now, my word-processing documents make full use of styles, and in that context 
I've transcended tabs completely.  For casual documents I might find myself 
falling back into the email-like habit of pushing "Enter" twice between 
paragraphs.  But when it's time to get serious, I define an appropriate 
paragraph style.

I have read about elastic tabstops.  If they become a standard and address my 
needs (it looks like they should), I will be happy to switch.

If you want to make your head spin, investigate how to represent polyphonic 
musical notation in a data structure that ensures it will be drawn accurately 
on staff paper, as well as played correctly by a synthesizer.  Code is child's 
play by comparison.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to package my project and make it ready to be installed by using pip

[Daiyue Weng]

If I tried

pip3 install git+https://user_n...@bitbucket.org/user_name/project_name.git

the package would get installed, but there are no python files that have
been installed in /usr/local/lib/python3.5/dist-packages/project_name

Hence I couldn't import any class in the package in python.

I am wondering how to fix this.

On 20 March 2017 at 16:37, Daiyue Weng  wrote:

> I have been Python Packaging User Guide ,
> and I created a setup.py in my PyCharm project root,
>
> from setuptools import setup, find_packages
> from os import path
>
> here = path.abspath(path.dirname(__file__))
>
> packages = find_packages(exclude=['contrib', 'docs', 'tests*'])
>
> setup(
> name='lumar_stackdriver_logging',
>
> description='A sample Python project',
>
>
> author='project_dev',
> author_email='pypa-...@googlegroups.com',
>
>
> # Choose your license
> license='GNU GPL',
>
> # See https://pypi.python.org/pypi?%3Aaction=list_classifiers
> classifiers=[
> # How mature is this project? Common values are
> #   3 - Alpha
> #   4 - Beta
> #   5 - Production/Stable
> 'Development Status :: 3 - Alpha',
>
> # Indicate who your project is intended for
> 'Intended Audience :: Project Developers',
> 'Topic :: System :: Logging',
>
> # Pick your license as you wish (should match "license" above)
> 'License :: OSI Approved :: GNU General Public License (GPL)',
>
> # Specify the Python versions you support here. In particular, ensure
> # that you indicate whether you support Python 2, Python 3 or both.
> # 'Programming Language :: Python :: 3',
> # 'Programming Language :: Python :: 3.2',
> # 'Programming Language :: Python :: 3.3',
> # 'Programming Language :: Python :: 3.4',
> 'Programming Language :: Python :: 3.5',
> ],
>
> # What does your project relate to?
> keywords='sample setuptools development',
>
>
> # You can just specify the packages manually here if your project is
> # simple. Or you can use find_packages().
> packages=packages,
> )
>
>
> I uploaded/committed the project into a Git repo/BitBucket, what I want is 
> anyone who can access the repo, can deploy the project from the repo to their 
> machines using pip.
>
> I am wondering how to achieve that?
>
>
> Many thanks
>
>
> On 20 March 2017 at 11:57, Daiyue Weng  wrote:
>
>> thanks, i am reading it.
>>
>> On 20 March 2017 at 11:50, Glenn Hutchings  wrote:
>>
>>> On Monday, 20 March 2017 11:36:34 UTC, Daiyue Weng  wrote:
>>> > Hi, I using Python 3.5.2 on Linux Mint 18.1, and I am wondering how to
>>> > package my PyCharm Python project as a module so that it can installed
>>> by
>>> > someone else by using pip. Like what tools and script I need to use or
>>> > write in order to do that.
>>>
>>> A good place to start is https://packaging.python.org.
>>> --
>>> https://mail.python.org/mailman/listinfo/python-list
>>>
>>
>>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: relative paths connect using python

[Steve D'Aprano]

On Tue, 21 Mar 2017 04:05 am, Xristos Xristoou wrote:

> i have a little confused problem. i want to store some paths from images
> using python 2.7 in windows 10. i have some relative path like this
> var1='C:/my/store/path' 

That's not a relative path, that's an absolute path.


> and in the final folder where in my example is the 
> name 'path' inside that folder i have some images like this : -path
>-myimage_1010_im.png
>-myimage_1010_im1.png
>-myimage_1010_im3.png
>-myimage_1020_im.png
>-myimage_1020_im1.png
> can i connect my relative path like var1 


var1 is not a relative path. It is an absolute path. Absolute paths start
with a drive letter like C. Relative paths have no drive letter and start
in the current working directory.


> with the images using only the 
> number of the mid name of images and finaly i take the full original path
> like this var1='C:/my/store/path/myimage_1010_im.png' ? 

I am afraid I have no idea what your code is doing. Instead of describing
what your Python code isn't doing, can you show the code so we can see what
it is doing?

And please use variable names that mean something.

# terrible variable names
var, var1, var2

# good variable names
directory_name, full_path, filename



> i try something 
> but not work import os cwd = os.getcwd()
> path = os.path.join(cwd, "my_file")

That works perfectly for me:

py> import os
py> cwd = os.getcwd()
py> path = os.path.join(cwd, "my_file")
py> print path
/home/steve/my_file


What were you expecting it to do? Can you tell us what result you expected,
and what result you got?





-- 
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"?

[Steve D'Aprano]

On Tue, 21 Mar 2017 02:40 am, Tobiah 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 can't think of any classic Unix tool that behaves in a way that would
> support this point of view.

And yet I'm forever being told by my Linux sys admin work mates "don't use
tabs, because they break everything". For another example, see JMZ's essay
(its already been linked to twice in this thread, look it up).

We've had a similar attitude right here from Marko, who insists that
anything except 8-column tabs is the Devil's Work. (Or something like
that -- to be perfectly honest, I'm not really sure I understand *what*
Marko's objection is.)

So okay, if tabs work fine with Unix tools, why do so many Unix people avoid
tabs as if they were radioactive plague?




-- 
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: relative paths connect using python

[jladasky]

On Monday, March 20, 2017 at 10:05:33 AM UTC-7, Xristos Xristoou wrote:
> i have a little confused problem. i want to store some paths from images 
> using python 2.7 in windows 10.
> i have some relative path like this var1='C:/my/store/path' and in the final 
> folder where in my example is the name 'path' inside that folder i have some 
> images like this :
> -path
>-myimage_1010_im.png
>-myimage_1010_im1.png
>-myimage_1010_im3.png
>-myimage_1020_im.png
>-myimage_1020_im1.png
> can i connect my relative path like var1 with the images using only the 
> number of the mid name of images and finaly i take the full original path 
> like this var1='C:/my/store/path/myimage_1010_im.png' ?
> i try something but not work 
> import os
> cwd = os.getcwd()
> path = os.path.join(cwd, "my_file")

I think you are new here.  In order to get the best possible assistance, you 
always need to share as much information as you can.

You posted your code.  That's a good start.

You did not post the error message you received. "i try something but not work" 
is never enough information.  Post your actual error messages as well.  What do 
they say?

Are you new to programming or just to Python?  Reading the error messages is 
sometimes hard for new programmers.  But once you can read them, you can fix 
your own problems.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: relative paths connect using python

[Xristos Xristoou]

Τη Δευτέρα, 20 Μαρτίου 2017 - 7:05:33 μ.μ. UTC+2, ο χρήστης Xristos Xristoou 
έγραψε:
> i have a little confused problem. i want to store some paths from images 
> using python 2.7 in windows 10.
> i have some relative path like this var1='C:/my/store/path' and in the final 
> folder where in my example is the name 'path' inside that folder i have some 
> images like this :
> -path
>-myimage_1010_im.png
>-myimage_1010_im1.png
>-myimage_1010_im3.png
>-myimage_1020_im.png
>-myimage_1020_im1.png
> can i connect my relative path like var1 with the images using only the 
> number of the mid name of images and finaly i take the full original path 
> like this var1='C:/my/store/path/myimage_1010_im.png' ?
> i try something but not work 
> import os
> cwd = os.getcwd()
> path = os.path.join(cwd, "my_file")

i want like this
a=1010
path = os.path.join(cwd, a")
print path

and the path i need full absolute path like this : 
var1='C:/my/store/path/myimage_1010_im.png'

in my first code i dont have error but i take wrong for me path not full
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: __del__ is not called after creating a new reference

[Steve D'Aprano]

On Sat, 18 Mar 2017 01:54 am, Oleg Nesterov wrote:

[...]
> However, this trivial test-case
> 
> class C:
> def __del__(self):
> print("DEL")
> global X
> X = self
> C()
> print(X)
> X = 0
> print(X)
> 
> shows that __del__ is called only once, it is not called again after "X =
> 0":
> 
> DEL
> <__main__.C object at 0x7f067695f4a8>
> 0

I cannot confirm that test case. When I try it, I get NameError:


py> class C:
... def __del__(self):
... print("DEL")
... global X
... X = self
...
py> C()
<__main__.C object at 0xb785c48c>
py> print(X)
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'X' is not defined
py> X = 0
py> print(X)
0


I've tried it in both Python 2.7 and 3.5 and get the same NameError. I
suspect that you are not running the code you have shown us.




-- 
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: __del__ is not called after creating a new reference

[Steve D'Aprano]

On Tue, 21 Mar 2017 04:51 am, Steve D'Aprano wrote:

> On Sat, 18 Mar 2017 01:54 am, Oleg Nesterov wrote:
> 
> [...]
>> However, this trivial test-case
[...]

> I cannot confirm that test case. When I try it, I get NameError:

Ah, never mind! I was running this in the interactive interpreter, and
forgot that it saves a reference to the last result using _ so of course
the __del__ method didn't run at all.


I changed the code to run:

c = C()
del c

and now I'm seeing the same thing as you: DEL is only printed once.



-- 
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: relative paths connect using python

[Michael Torrie]

On 03/20/2017 11:49 AM, Xristos Xristoou wrote:

> and the path i need full absolute path like this : 
> var1='C:/my/store/path/myimage_1010_im.png'
> 
> in my first code i dont have error but i take wrong for me path not full

Since you have not provided any sample output from your program, there's
no way we can replicate the problem you are having.  Please provide the
output from your program (cut and paste it from the cmd.exe window).
You may also want to print out the other variables, such as cwd, so you
can tell exactly what it's doing.

Hopefully through this process you can learn how to debug programs.


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

Re: relative paths connect using python

[alister]

On Mon, 20 Mar 2017 10:49:39 -0700, Xristos Xristoou wrote:

> Τη Δευτέρα, 20 Μαρτίου 2017 - 7:05:33 μ.μ. UTC+2, ο χρήστης Xristos
> Xristoou έγραψε:
>> i have a little confused problem. i want to store some paths from
>> images using python 2.7 in windows 10.
>> i have some relative path like this var1='C:/my/store/path' and in the
>> final folder where in my example is the name 'path' inside that folder
>> i have some images like this :
>> -path
>>-myimage_1010_im.png -myimage_1010_im1.png -myimage_1010_im3.png
>>-myimage_1020_im.png -myimage_1020_im1.png
>> can i connect my relative path like var1 with the images using only the
>> number of the mid name of images and finaly i take the full original
>> path like this var1='C:/my/store/path/myimage_1010_im.png' ?
>> i try something but not work import os cwd = os.getcwd()
>> path = os.path.join(cwd, "my_file")
> 
> i want like this a=1010 path = os.path.join(cwd, a")
> print path
> 
> and the path i need full absolute path like this :
> var1='C:/my/store/path/myimage_1010_im.png'
> 
> in my first code i dont have error but i take wrong for me path not full

without specifying what you expect to see & what you are actually seeing 
it is difficult for anyone to understand your problem let alon provide 
the solution. 

that said it looks like you need to develop your debugging skills so that 
you can hep yourself, try adding print statements at critical points in 
your program to check that your variables contain what you think they 
should ate each stage, this will help you pinpoint the point in your code 
you need to investigate.

example:

cwd=os.getcwd()
print (cwd) // is cwd what you expect? if not why not
path = os.path.join(cwd,'myfile')
print (path) // is path what you expect  ?if not why not?

when you identify the part that is wrong post back with what you expect & 
what you get.
 
I was making donuts and now I'm on a bus!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Joel Goldstick]

On Mon, Mar 20, 2017 at 1:39 PM, Steve D'Aprano
 wrote:
> On Tue, 21 Mar 2017 02:40 am, Tobiah 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 can't think of any classic Unix tool that behaves in a way that would
>> support this point of view.
>
> And yet I'm forever being told by my Linux sys admin work mates "don't use
> tabs, because they break everything". For another example, see JMZ's essay
> (its already been linked to twice in this thread, look it up).
>
> We've had a similar attitude right here from Marko, who insists that
> anything except 8-column tabs is the Devil's Work. (Or something like
> that -- to be perfectly honest, I'm not really sure I understand *what*
> Marko's objection is.)
>
> So okay, if tabs work fine with Unix tools, why do so many Unix people avoid
> tabs as if they were radioactive plague?
>
>
>
>
> --
> 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

I was the first to post that this topic would go nowhere.  77 posts
later, for some reason the word 'spaceist' bothers me.  Why do people
debate spaces versus tabs?  I don't think it has to do with spaces or
tabs, but something more sociological or psychological.

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[alister]

On Sun, 19 Mar 2017 23:01:22 +, Erik wrote:

> 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.

I have just tested this with geany & it works a charm,

personally I prefer tabs for setting my indent levels, it feels more 
logical & breaks nothing if the font or tab size is changed but votes 
have been counted & the jury has returned a verdict

Spaces are the preferred option, but you are still able to make your own 
choice.




-- 
It's a very *__UN*lucky week in which to be took dead.
-- Churchy La Femme
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Tue, Mar 21, 2017 at 4:39 AM, Steve D'Aprano
 wrote:
> And yet I'm forever being told by my Linux sys admin work mates "don't use
> tabs, because they break everything". For another example, see JMZ's essay
> (its already been linked to twice in this thread, look it up).
>
> We've had a similar attitude right here from Marko, who insists that
> anything except 8-column tabs is the Devil's Work. (Or something like
> that -- to be perfectly honest, I'm not really sure I understand *what*
> Marko's objection is.)
>
> So okay, if tabs work fine with Unix tools, why do so many Unix people avoid
> tabs as if they were radioactive plague?

Can you ask your workmates to elaborate? I'd love to hear.

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

Re: Who are the "spacists"?

[Marko Rauhamaa]

Steve D'Aprano :

> On Tue, 21 Mar 2017 12:30 am, Marko Rauhamaa wrote:
>
>> Unicode was 25 years late to the game
>
> I don't understand that comment. Are you suggesting that the oldest
> convention wins? The Unix 8-column convention is older than Unicode, so it
> wins?

The 8-column convention is older, alive and well on Unix so it wins on
Unix.

> Well... in that case, there are tab conventions that pre-date Unix, e.g.
> those used by COBOL.

COBOL is not highly relevant in the Unix world.

> But wait... before there was COBOL, there were *typewriters*.

Typewriters and teletypes are indeed behind the original intended
(pre-Unix) semantics of things like BS, HT, CR and LF. However, they
acquired modified meanings in Unix. For example, CR on input is
converted to an LF, and LF on output is converted to a CRLF.

> So there you go. Unix was 50+ years late to the game.

Unix is normative for Unix.

I seem to recall, though, that the same 8-column interpretation was
there with CP/M and MS-DOS. The practice must be older:

   In practice, settable tab stops were rather quickly replaced with
   fixed tab stops, de facto standardized at every multiple of 8
   characters horizontally, and every 6 lines vertically (typically one
   inch vertically). A printing program could easily send the necessary
   spaces or line feeds to move to any position wanted on a form, and
   this was far more reliable than the modal and non-standard methods of
   setting tab stops. Tab characters simply became a form of data
   compression.

   https://en.wikipedia.org/wiki/Tab_key>


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

Re: Who are the "spacists"?

[Chris Angelico]

On Tue, Mar 21, 2017 at 5:57 AM, alister  wrote:
> I have just tested this with geany & it works a charm,
>
> personally I prefer tabs for setting my indent levels, it feels more
> logical & breaks nothing if the font or tab size is changed but votes
> have been counted & the jury has returned a verdict
>
> Spaces are the preferred option, but you are still able to make your own
> choice.

I'm so glad the world isn't a democracy. "The votes have been counted"
means nothing. :)

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

Re: Who are the "spacists"?

[alister]

On Tue, 21 Mar 2017 06:04:12 +1100, Chris Angelico wrote:

> On Tue, Mar 21, 2017 at 5:57 AM, alister 
> wrote:
>> I have just tested this with geany & it works a charm,
>>
>> personally I prefer tabs for setting my indent levels, it feels more
>> logical & breaks nothing if the font or tab size is changed but votes
>> have been counted & the jury has returned a verdict
>>
>> Spaces are the preferred option, but you are still able to make your
>> own choice.
> 
> I'm so glad the world isn't a democracy. "The votes have been counted"
> means nothing. :)
> 
> ChrisA

you know as well as Id that I meant this discussion was had many years 
ago & the decision was made.

to be honest I don't know whether it was by a consensus of the community 
or simply Guido tossing a coin. either way does not matter it is not 
something that is going to change now.

fortunately both tabs & spaces are still supported so individual 
programmes can still make their own decisions, the only time it makes any 
difference is when working on a collaboration with other programmers when 
style guides have to be agreed.

if I was to say only a Nazi world try to enforce one or the other at this 
stage in the languages evolution can we call Godwin's on this un-
Productive debate ;-)



-- 
Remembering is for those who have forgotten.
-- Chinese proverb
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Tue, Mar 21, 2017 at 8:19 AM, alister  wrote:
> On Tue, 21 Mar 2017 06:04:12 +1100, Chris Angelico wrote:
>
>> On Tue, Mar 21, 2017 at 5:57 AM, alister 
>> wrote:
>>> I have just tested this with geany & it works a charm,
>>>
>>> personally I prefer tabs for setting my indent levels, it feels more
>>> logical & breaks nothing if the font or tab size is changed but votes
>>> have been counted & the jury has returned a verdict
>>>
>>> Spaces are the preferred option, but you are still able to make your
>>> own choice.
>>
>> I'm so glad the world isn't a democracy. "The votes have been counted"
>> means nothing. :)
>>
>> ChrisA
>
> you know as well as Id that I meant this discussion was had many years
> ago & the decision was made.
>
> to be honest I don't know whether it was by a consensus of the community
> or simply Guido tossing a coin. either way does not matter it is not
> something that is going to change now.
>
> fortunately both tabs & spaces are still supported so individual
> programmes can still make their own decisions, the only time it makes any
> difference is when working on a collaboration with other programmers when
> style guides have to be agreed.

See, that's the thing. PEP 7 and PEP 8 govern the source code for the
Python language itself, and there is no requirement to follow their
recommendations in other projects. If you choose to adopt PEP 8 as the
basis of your style guide, you should still make your own decisions on
the points where the specific recommendations are less important than
internal consistency - and tabs vs spaces is definitely one of them.
The decision has NOT been made for the entire Python community.

And even the decision governing the standard library was not on the
basis of a vote. It was the basis of a considered decision by the
person responsible. Like I said, the world - and Python - is not a
democracy. :)

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

Re: Who are the "spacists"?

[Gregory Ewing]

Steve D'Aprano wrote:

But wait... before there was COBOL, there were *typewriters*. Its been many
years since I've had my hands on a manual typewriter, but if I remember
correctly the standard default tab setting was 1 inch.


I haven't used many manual typewriters, but on the ones I have
used, there were no "standard" tab stops -- you configured them
yourself, wherever you wanted.

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

Re: Who are the "spacists"?

[Mikhail V]

On 20 March 2017 at 16:19, BartC  wrote:
> On 20/03/2017 14:32, Chris Angelico wrote:
>>
>> On Tue, Mar 21, 2017 at 1:24 AM, BartC  wrote:
>>>
>>> But it would be better IMO if tabs were used, with some scheme for
>>> suggesting the tab width (or set of tab stops) that is recommended (eg. a
>>> comment at the top).
>>
>>
>> If you absolutely have to, then sure, put a directive in some
>> machine-readable way at the top or bottom of the file. It's like the
>> coding cookie that Python follows - some editors also respect it. But
>> I would prefer to just use tabs *without* suggesting a width, because
>> each one represents *one indent*. Not a number of spaces. One
>> indentation level.
>
>
> For leading tabs at the start of a new statement that wouldn't be a problem.
> Changing the tab width shown just spreads out statements more, or less,
> horizontally.
>
> It works - there is no jarring misalignment - because each tab corresponds
> to the same N spaces, whatever N happens to be.
>
> But tabs are also used after statements, before comments for example, or to
> line up elements in tables. Then it doesn't work, because tabs may represent
> 1 to N spaces:
>
> Using N=4, with 1 tab before each number:
>
> (one,   1), #comment 1
> (two,   2), #comment 2
> (three, 3), #comment 3
> ...

Well, the definition of tabwidth in file could help only in theory,
As already said, one cannot define a tab as N charaters,
since character size is not a constant.
Don't assume that one uses monospaced
editor. For screen, generally, the units are pixels.
(warning: thinking too much about it can be brain-damaging)

Reasonable solution is just to be patient and wait
before IDEs can render tables inside a document depending
on the context. This would mean exactly 1 tab as separator.
Before that I'd say just don't worry much if
your layout will look not so nice, and not be so fanatic
with inserting multi-column content into the source code.

Tab-separated tables is actually what I use on a daily
basis, e.g copy-pasting from Excell to TXT file back
and forth, and my scripts parse tables usually as tab-separated
txt file.

And I'd say again, don't spam multiple spaces anywhere, it will be harder
to pluck them out for the collegues (and probably for the
document creator in the future).
My rule of thumb: if I see multiple spaces in any document,
something is probably wrong (except ASCII art:))).

So if one'd ask, this would be roughly my styleguide.


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

Re: cross python version randomness

[Kev Dwyer]

Robin Becker wrote:

> Is there a way to get the same sequences of random numbers in python 2.7
> and python >= 3.3?
> 
> I notice that this simple script produces different values in python 2.7
> and >=3.3
> 
> C:\code\hg-repos\reportlab>cat s.py
> import sys, random
> print(sys.version)
> random.seed(103)
> for i in range(5):
>  print(i, random.randint(10,25))
> 
> C:\code\hg-repos\reportlab>\python27\python s.py
> 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 64 bit
> (AMD64)] 0 25
> 1 17
> 2 21
> 3 21
> 4 13
> 
> C:\code\hg-repos\reportlab>\python33\python s.py
> 3.3.5 (v3.3.5:62cf4e77f785, Mar  9 2014, 10:35:05) [MSC v.1600 64 bit
> (AMD64)] 0 24
> 1 16
> 2 12
> 3 13
> 4 22
> 
> However, when I use random.random() all seems to be the same so this
> script C:\code\hg-repos\reportlab>cat u.py
> import sys, random
> print(sys.version)
> random.seed(103)
> for i in range(5):
>  print(i, random.random())
> 
> seems to be fine
> 
> 
> C:\code\hg-repos\reportlab>\python27\python u.py
> 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 64 bit
> (AMD64)] (0, 0.9790501200727744)
> (1, 0.45629827629184827)
> (2, 0.7188470341002364)
> (3, 0.7348862425853395)
> (4, 0.21490166849706338)
> 
> C:\code\hg-repos\reportlab>\python33\python u.py
> 3.3.5 (v3.3.5:62cf4e77f785, Mar  9 2014, 10:35:05) [MSC v.1600 64 bit
> (AMD64)] 0 0.9790501200727744
> 1 0.45629827629184827
> 2 0.7188470341002364
> 3 0.7348862425853395
> 4 0.21490166849706338
> 
> presumably randint is doing something different to get its values.


The docs [https://docs.python.org/3/library/random.html#random.randrange] 
for randrange have this note:

Changed in version 3.2: randrange() is more sophisticated about producing 
equally distributed values. Formerly it used a style like int(random()*n) 
which could produce slightly uneven distributions.

Maybe that's the explanation?  Unfortunately I don't have an install of 
3.0/1 to test against.

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