Re: Can't run program

[Bob Gailer]

On May 19, 2020 9:02 PM, "Ryan Harrington" <
ryan.harring...@whitesourcesoftware.com> wrote:
>
> Hi - I'm not the least bit technical. Trying to learn through YouTube.
I've
> gotten exit code 1, 2, 106. Tried setting up the project interpreter and
> can't figure it out. Tried uninstalling and reinstalling everything and
> still having problems. Any feedback appreciated.

We need a lot more information in order to help you. Operating system?
Where did you get the installation file? what does "everything" mean? Show
us the steps you took and whatever error messages you got, or whatever
"still having problems" means.

I'm pretty sure this list does not take attachments, so you either need to
copy and paste what you might have typed and any results from that, or put
images in a place like pastebin and give us the link.

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

Re: why no camelCase in PEP 8?

[Jim]

On 5/19/20 3:49 PM, Chris Angelico wrote:

On Wed, May 20, 2020 at 6:38 AM Jim  wrote:


On 5/19/20 1:24 PM, Chris Angelico wrote:

On Wed, May 20, 2020 at 4:03 AM Schachner, Joseph
 wrote:


And, because '_' looks sort of like a space, the individual words are more 
easily readable.  notEveyoneThinksReadingCamelCaseIsEasy.



Me: "What does casels mean?"

*beat*

Me: "Well, I guess that's the point then, isn't it."

ChrisA



Couldn't resist: Why not Chris_A :)


Heh. Actually a fair question! It's actually been my shorthand name
for many many years, and originally I used the username "chrisa" since
that was the email convention at the company. I later started
uppercasing it to avoid being thought of as a "Christa" or somesuch,
and wanted to remain compatible with the existing address, so case
changes were all I'd do. But if I were to identify myself in a more
Pythonic way, it would be Chris_Angelico.

Backward compatibility trumps PEP 8.

ChrisA



Fair point.

Jim

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

Re: Strings: double versus single quotes

[Souvik Dutta]

I love and use only singel quotes. I think that looks clean... Nothing else.

Souvik flutter dev

On Tue, May 19, 2020, 11:50 PM Manfred Lotz  wrote:

> Hi there,
> I am asking myself if I should preferably use single or double quotes
> for strings?
>
> If I need a single quote in a string I would use double quotes for the
> whole string and vice versa. For f-strings I mostly see double
> quotes but single quotes would work as well I think.
>
> Is there a recommendation?
>
>
> --
> Manfred
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can't run program

[Yong Pang]

Hi

Ryan Harrington wrote:

Hi - I'm not the least bit technical. Trying to learn through YouTube. I've
gotten exit code 1, 2, 106. Tried setting up the project interpreter and
can't figure it out. Tried uninstalling and reinstalling everything and
still having problems. Any feedback appreciated.


You should be able to paste the code here before anyone others can help you.

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

Re: Strings: double versus single quotes

[Terry Reedy]

On 5/19/2020 2:10 PM, Manfred Lotz wrote:

Hi there,
I am asking myself if I should preferably use single or double quotes
for strings?

If I need a single quote in a string I would use double quotes for the
whole string and vice versa. For f-strings I mostly see double
quotes but single quotes would work as well I think.

Is there a recommendation?


I personally like to use "This is a phrase or sentence" while '0', '\n', 
and 'work' are items or words.

# And this is a comment 'quoted' by '#' and '\n'.


--
Terry Jan Reedy

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

Can't run program

[Ryan Harrington]

Hi - I'm not the least bit technical. Trying to learn through YouTube. I've
gotten exit code 1, 2, 106. Tried setting up the project interpreter and
can't figure it out. Tried uninstalling and reinstalling everything and
still having problems. Any feedback appreciated.

Thank you,
--

Ryan Harrington
Director of Sales
M - 860-303-2265
WhiteSourceSoftware.com 
Boston, MA, USA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

[Alan Gauld via Python-list]

On 19/05/2020 19:10, Manfred Lotz wrote:
> Hi there,
> I am asking myself if I should preferably use single or double quotes
> for strings?

Personally laziness wins every time. Single quotes only require one
finger from the home position using my right hand, double quotes
require two and a big movement of my left hand from home.

So I use single quotes most of the time (ie unless it contains
a single quote)


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


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

Re: Strings: double versus single quotes

[Cameron Simpson]

On 19May2020 22:04, Manfred Lotz  wrote:

On Tue, 19 May 2020 13:36:54 -0500
Tim Chase  wrote:

On 2020-05-19 20:10, Manfred Lotz wrote:
> I am asking myself if I should preferably use single or double
> quotes for strings?

I'd say your consistency matters more than which one you choose.

[...]

I personally use habits from my C days:  double-quotes for everything
except single characters for which I use a single-quote:

  if 'e' in "hello":

as in indicator that I'm using it as a single character rather than
as a string.

I don't have a firm rule for myself if a string contains
double-quotes.  It doesn't happen often for me in a case where I
couldn't use a triple-quoted string or that I am refering to it as a
single character. [...]


I am influenced by Perl which I used before. In Perl I used double
quoted strings when I wanted interpolation. Otherwise single quoted
strings. In Rust (or C) it is double quotes for strings and single
quotes for characters.


And I, the shell (where single quotes are "raw" and double quotes allow 
parameter substitution).  So I use single quotes for plain old strings 
and double quotes when I'm going to be formatting the string with % 
(therefore, in most logging calls).


Personally I find double quotes visually noisy, and prefer single 
quotes. Most of the time.


This is one of the reasons I autoformat with yapf (which doesn't change 
my quoting) rather than black (which is very opinionated and also 
untunable, and _does_ change my quotes).


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

Re: Missing python curses functions?

[Cameron Simpson]

On 19May2020 20:53, Alan Gauld  wrote:

Is anyone other than me still even using Python curses? :-)


Well, not curses full on (due to lack of time) but my cs.upd module uses 
the ti_getstr() et al functions for cursor motions and insert/delete 
line, etc.


It may be that the person who wrote the curses module simply got tired.  
Or it predates the get_attr calls (not sure now old they are).


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

Re: Missing python curses functions?

[Bill Campbell]

On Tue, May 19, 2020, Alan Gauld via Python-list wrote:
>During my Covid19 lock-down I thought I'd spend my time translating
>the "Linux Curses Programming HOWTO" document into Pythonic curses.
>
>One of the functions discussed that does not appear to have
>a Python equivalent is attr_get() which gets the current
>attributes.

I haven't looked for it.

...
>Is anyone other than me still even using Python curses? :-)

Raises hand.

Bill
-- 
INTERNET:   b...@celestial.com  Bill Campbell; Celestial Software LLC
URL: http://www2.celestial.com/ 6641 E. Mercer Way
Mobile: (206) 947-5591  PO Box 820
Fax:(206) 232-9186  Mercer Island, WA 98040-0820

Democracy Is Mob Rule with Income Taxes
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [RELEASE] Python 3.9.0b1 is now available for testing

[Robin Becker]

..

robin@minikat:~/devel/reportlab
$ $HOME/LOCAL/3.9b1/bin/python3.9
Python 3.9.0b1 (default, May 19 2020, 12:50:30) [GCC 10.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import distutils

/home/robin/LOCAL/3.9b1/lib/python3.9/distutils/__init__.py:15: UserWarning: 
The virtualenv distutils package at %s appears to be in the same location as 
the system distutils?
  warnings.warn("The virtualenv distutils package at %s appears to be in the same 
location as the system distutils?")

distutils.__path__

['/home/robin/LOCAL/3.9b1/lib/python3.9/distutils']

distutils.__file__

'/home/robin/LOCAL/3.9b1/lib/python3.9/distutils/__init__.py'


is this a bug or have I built python 3.9.0b1 wrongly?


I think that is correct __file__ value. What are you expecting to see?


I wasn't expecting the warning at all, but in fact this appears to be an interaction caused by installing 
virualenv==16.2.0 into my home built python3.9.0b1 and then using it to create a virtual environment. For some reason 
that creates a problem in the base python which I haven't yet fully explained.


I can build python3.9.9b1 virtualenvs using archlinux python 3.8.2 with

/bin/python -mvirtualenv -p /home/robin/LOCAL/3.9b1/bin/python3.9 myenv

I prefer the older virtualenv because it makes python executables which I can link to rather than always using an 
explicit path.


Sorry for the noise.


Barry


--
Robin Becker

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




O


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

Re: [RELEASE] Python 3.9.0b1 is now available for testing

[Barry]

> On 19 May 2020, at 21:36, Robin Becker  wrote:
> 
> On 19/05/2020 10:49, Łukasz Langa wrote:
>> On behalf of the entire Python development community, and the currently 
>> serving Python release team in particular, I’m pleased to announce the 
>> release of Python 3.9.0b1. Get it here:
>> https://www.python.org/downloads/release/python-390b1/ 
>> 
>> This is a beta preview of Python 3.9
>> Python 3.9 is still in development. This release, 3.9.0b1, is the first of 
>> four planned beta release previews.
>> Beta release previews are intended to give the wider community the 
>> opportunity to test new features and bug fixes and to prepare their projects 
>> to support the new feature release.
>> Call to action
> .
> 
> I built python3.9.0b1 from source using the standard configure make dance eg
> 
> ./configure --prefix=$HOME/LOCAL/3.9b1
> make && make install
> 
> that appeared to work fine and I seem to get a working python. However, I 
> seem to have an issue with the distutils package
> 
> 
>> robin@minikat:~/devel/reportlab
>> $ $HOME/LOCAL/3.9b1/bin/python3.9
>> Python 3.9.0b1 (default, May 19 2020, 12:50:30) [GCC 10.1.0] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
> import distutils
>> /home/robin/LOCAL/3.9b1/lib/python3.9/distutils/__init__.py:15: UserWarning: 
>> The virtualenv distutils package at %s appears to be in the same location as 
>> the system distutils?
>>  warnings.warn("The virtualenv distutils package at %s appears to be in the 
>> same location as the system distutils?")
> distutils.__path__
>> ['/home/robin/LOCAL/3.9b1/lib/python3.9/distutils']
> distutils.__file__
>> '/home/robin/LOCAL/3.9b1/lib/python3.9/distutils/__init__.py'
> 
> is this a bug or have I built python 3.9.0b1 wrongly?

I think that is correct __file__ value. What are you expecting to see?

Barry

> --
> Robin Becker
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

Re: Strings: double versus single quotes

[Manfred Lotz]

On Tue, 19 May 2020 13:36:54 -0500
Tim Chase  wrote:

> On 2020-05-19 20:10, Manfred Lotz wrote:
> > Hi there,
> > I am asking myself if I should preferably use single or double
> > quotes for strings?  
> 
> I'd say your consistency matters more than which one you choose.
> 
> According to a recent observation by Raymond H.
> 
> """
>   Over time, the #python world has shown increasing preference
>   for double quotes:  "hello" versus 'hello'.
> 
>   Perhaps, this is due to the persistent influence of JSON,
>   PyCharm, Black, and plain English.
> 
>   In contrast, the interpreter itself prefers single quotes:
> 
>   >>> "hello"  
>   'hello'
> """
> 
> https://twitter.com/raymondh/status/1259209765072154624
> 
> I think the worst choice is to be haphazard in your usage with a
> hodgepodge of single/double quotes.
> 
> I personally use habits from my C days:  double-quotes for everything
> except single characters for which I use a single-quote:
> 
>   if 'e' in "hello":
> 
> as in indicator that I'm using it as a single character rather than
> as a string.
> 
> I don't have a firm rule for myself if a string contains
> double-quotes.  It doesn't happen often for me in a case where I
> couldn't use a triple-quoted string or that I am refering to it as a
> single character.
> 
> -tkc
> 
> 

I am influenced by Perl which I used before. In Perl I used double
quoted strings when I wanted interpolation. Otherwise single quoted
strings. In Rust (or C) it is double quotes for strings and single
quotes for characters. 

You may be right. Consistency is a good thing. So, I have to decide for
what I use and be consistent thereafter.

-- 
Manfred


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

Re: why no camelCase in PEP 8?

[DL Neil via Python-list]

On 20/05/20 8:49 AM, Chris Angelico wrote:

On Wed, May 20, 2020 at 6:38 AM Jim  wrote:


On 5/19/20 1:24 PM, Chris Angelico wrote:

On Wed, May 20, 2020 at 4:03 AM Schachner, Joseph
 wrote:


And, because '_' looks sort of like a space, the individual words are more 
easily readable.  notEveyoneThinksReadingCamelCaseIsEasy.



Me: "What does casels mean?"


Chris
Angelico
Shortens
Every
Long-name
Savagely
?
Significantly
?
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: why no camelCase in PEP 8?

[Chris Angelico]

On Wed, May 20, 2020 at 6:38 AM Jim  wrote:
>
> On 5/19/20 1:24 PM, Chris Angelico wrote:
> > On Wed, May 20, 2020 at 4:03 AM Schachner, Joseph
> >  wrote:
> >>
> >> And, because '_' looks sort of like a space, the individual words are more 
> >> easily readable.  notEveyoneThinksReadingCamelCaseIsEasy.
> >>
> >
> > Me: "What does casels mean?"
> >
> > *beat*
> >
> > Me: "Well, I guess that's the point then, isn't it."
> >
> > ChrisA
> >
>
> Couldn't resist: Why not Chris_A :)

Heh. Actually a fair question! It's actually been my shorthand name
for many many years, and originally I used the username "chrisa" since
that was the email convention at the company. I later started
uppercasing it to avoid being thought of as a "Christa" or somesuch,
and wanted to remain compatible with the existing address, so case
changes were all I'd do. But if I were to identify myself in a more
Pythonic way, it would be Chris_Angelico.

Backward compatibility trumps PEP 8.

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

Re: Strings: double versus single quotes

[Ethan Furman]

On 05/19/2020 11:40 AM, Joel Goldstick wrote:


I thought triple quotes are for docstrings?


It's the recommendation, but double and single quotes work just fine, too -- at 
least for docstrings that fit an one line.

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

Re: why no camelCase in PEP 8?

[Jim]

On 5/19/20 1:24 PM, Chris Angelico wrote:

On Wed, May 20, 2020 at 4:03 AM Schachner, Joseph
 wrote:


And, because '_' looks sort of like a space, the individual words are more 
easily readable.  notEveyoneThinksReadingCamelCaseIsEasy.



Me: "What does casels mean?"

*beat*

Me: "Well, I guess that's the point then, isn't it."

ChrisA



Couldn't resist: Why not Chris_A :)

Jim

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

Missing python curses functions?

[Alan Gauld via Python-list]

During my Covid19 lock-down I thought I'd spend my time translating
the "Linux Curses Programming HOWTO" document into Pythonic curses.

One of the functions discussed that does not appear to have
a Python equivalent is attr_get() which gets the current
attributes.

There are functions aplenty for setting/unsetting attributes
but not for querying them. Or am I missing something?

I understand why we don't implement the print family of
functions - we can use string formatting combined with
addstr(). But I can't see equivalent python functionality
in the attr_get() case?

Is anyone other than me still even using Python curses? :-)

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


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

Re: [RELEASE] Python 3.9.0b1 is now available for testing

[Robin Becker]

On 19/05/2020 10:49, Łukasz Langa wrote:

On behalf of the entire Python development community, and the currently serving 
Python release team in particular, I’m pleased to announce the release of 
Python 3.9.0b1. Get it here:

https://www.python.org/downloads/release/python-390b1/ 


This is a beta preview of Python 3.9

Python 3.9 is still in development. This release, 3.9.0b1, is the first of four 
planned beta release previews.

Beta release previews are intended to give the wider community the opportunity 
to test new features and bug fixes and to prepare their projects to support the 
new feature release.

Call to action


.

I built python3.9.0b1 from source using the standard configure make dance eg

./configure --prefix=$HOME/LOCAL/3.9b1
make && make install

that appeared to work fine and I seem to get a working python. However, I seem 
to have an issue with the distutils package



robin@minikat:~/devel/reportlab
$ $HOME/LOCAL/3.9b1/bin/python3.9
Python 3.9.0b1 (default, May 19 2020, 12:50:30) 
[GCC 10.1.0] on linux

Type "help", "copyright", "credits" or "license" for more information.

import distutils

/home/robin/LOCAL/3.9b1/lib/python3.9/distutils/__init__.py:15: UserWarning: 
The virtualenv distutils package at %s appears to be in the same location as 
the system distutils?
  warnings.warn("The virtualenv distutils package at %s appears to be in the same 
location as the system distutils?")

distutils.__path__

['/home/robin/LOCAL/3.9b1/lib/python3.9/distutils']

distutils.__file__

'/home/robin/LOCAL/3.9b1/lib/python3.9/distutils/__init__.py'




is this a bug or have I built python 3.9.0b1 wrongly?
--
Robin Becker

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

Re: Strings: double versus single quotes

[Chris Angelico]

On Wed, May 20, 2020 at 4:42 AM Joel Goldstick  wrote:
>
> On Tue, May 19, 2020 at 2:27 PM Chris Angelico  wrote:
> >
> > On Wed, May 20, 2020 at 4:21 AM Manfred Lotz  wrote:
> > >
> > > Hi there,
> > > I am asking myself if I should preferably use single or double quotes
> > > for strings?
> > >
> > > If I need a single quote in a string I would use double quotes for the
> > > whole string and vice versa. For f-strings I mostly see double
> > > quotes but single quotes would work as well I think.
> > >
> > > Is there a recommendation?
> > >
> >
> > Nothing strong. I tend to use double quotes because I have a
> > background in C (where double quotes are for strings, single quotes
> > for characters), and double quotes are the recommendation for
> > docstrings (see PEP 258). If you tend to work a lot with SQL, you
> > might prefer single quotes. Use whatever makes you happy.
> >
> I thought triple quotes are for docstrings?

Yes, but triple double quotes ==> """ <== not triple single quotes ==>
''' <== is what PEP 258 recommends. The description is awkward but
it's still a place where the double-quote character (U+0022 QUOTATION
MARK) is the recommendation.

On Wed, May 20, 2020 at 4:46 AM DL Neil via Python-list
 wrote:
> @Chris: are you on the night-shift?
Yes? :)

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

Re: Strings: double versus single quotes

[Tim Chase]

On 2020-05-19 20:10, Manfred Lotz wrote:
> Hi there,
> I am asking myself if I should preferably use single or double
> quotes for strings?

I'd say your consistency matters more than which one you choose.

According to a recent observation by Raymond H.

"""
  Over time, the #python world has shown increasing preference
  for double quotes:  "hello" versus 'hello'.

  Perhaps, this is due to the persistent influence of JSON,
  PyCharm, Black, and plain English.

  In contrast, the interpreter itself prefers single quotes:

  >>> "hello"
  'hello'
"""

https://twitter.com/raymondh/status/1259209765072154624

I think the worst choice is to be haphazard in your usage with a
hodgepodge of single/double quotes.

I personally use habits from my C days:  double-quotes for everything
except single characters for which I use a single-quote:

  if 'e' in "hello":

as in indicator that I'm using it as a single character rather than
as a string.

I don't have a firm rule for myself if a string contains
double-quotes.  It doesn't happen often for me in a case where I
couldn't use a triple-quoted string or that I am refering to it as a
single character.

-tkc


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

Re: Strings: double versus single quotes

[DL Neil via Python-list]

On 20/05/20 6:26 AM, Chris Angelico wrote:

On Wed, May 20, 2020 at 4:21 AM Manfred Lotz  wrote:


Hi there,
I am asking myself if I should preferably use single or double quotes
for strings?

If I need a single quote in a string I would use double quotes for the
whole string and vice versa. For f-strings I mostly see double
quotes but single quotes would work as well I think.

Is there a recommendation?



Nothing strong. I tend to use double quotes because I have a
background in C (where double quotes are for strings, single quotes
for characters), and double quotes are the recommendation for
docstrings (see PEP 258). If you tend to work a lot with SQL, you
might prefer single quotes. Use whatever makes you happy.



Have been finding myself doing somewhat the opposite:

"a literal string"
f'a string featuring computation of { result }'

(never managed to make it as far as C in my alphabet skills, but yes, 
maybe SQL influences)


@Chris: are you on the night-shift?
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Determining index of range of values in a matrix

[DL Neil via Python-list]

On 19/05/20 6:40 AM, swaroop.sahoo...@gmail.com wrote:

Hi All,
I am using python for doing the following:
I have a matrix which has dimension of 174*993.
Each row of the matrix has some numbers in the range of 30-30.5.
I would like to determine the index of the numbers in the range of 30-30.5 in 
each row.
I can determine the index of the numbers in each row by using 
result1=np.where(np.logical_and(R[i,:]>= 30, R[i,:]<= 30.3))
But I would like to put the indexes in a matrix.
That is difficult because the number of indexes in each row will be different.
Can anyone help.



I'm probably less than sure that I've understood the problem. How will 
the indexes be used once the second 'matrix' is built?


Might it help to include some examples of data-rows, plus the expected 
index-row?


Are we to assume that you are using np?


As you allude, the usual structure of a "matrix" is that the number of 
'columns' in each 'row' is the same. However, the indexes might 
constitute a "sparse matrix".


Python however, has no 'matrix' data-structure, but does allow lists to 
contain lists (or dict[ionaries] to contain dicts) as a 2D 
data-structure. A list has no constraint, and no expectation that each 
'row' has the same number of columns.

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

[Joel Goldstick]

On Tue, May 19, 2020 at 2:27 PM Chris Angelico  wrote:
>
> On Wed, May 20, 2020 at 4:21 AM Manfred Lotz  wrote:
> >
> > Hi there,
> > I am asking myself if I should preferably use single or double quotes
> > for strings?
> >
> > If I need a single quote in a string I would use double quotes for the
> > whole string and vice versa. For f-strings I mostly see double
> > quotes but single quotes would work as well I think.
> >
> > Is there a recommendation?
> >
>
> Nothing strong. I tend to use double quotes because I have a
> background in C (where double quotes are for strings, single quotes
> for characters), and double quotes are the recommendation for
> docstrings (see PEP 258). If you tend to work a lot with SQL, you
> might prefer single quotes. Use whatever makes you happy.
>
I thought triple quotes are for docstrings?
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list



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

Re: Strings: double versus single quotes

[Chris Angelico]

On Wed, May 20, 2020 at 4:21 AM Manfred Lotz  wrote:
>
> Hi there,
> I am asking myself if I should preferably use single or double quotes
> for strings?
>
> If I need a single quote in a string I would use double quotes for the
> whole string and vice versa. For f-strings I mostly see double
> quotes but single quotes would work as well I think.
>
> Is there a recommendation?
>

Nothing strong. I tend to use double quotes because I have a
background in C (where double quotes are for strings, single quotes
for characters), and double quotes are the recommendation for
docstrings (see PEP 258). If you tend to work a lot with SQL, you
might prefer single quotes. Use whatever makes you happy.

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

Re: why no camelCase in PEP 8?

[Chris Angelico]

On Wed, May 20, 2020 at 4:03 AM Schachner, Joseph
 wrote:
>
> And, because '_' looks sort of like a space, the individual words are more 
> easily readable.  notEveyoneThinksReadingCamelCaseIsEasy.
>

Me: "What does casels mean?"

*beat*

Me: "Well, I guess that's the point then, isn't it."

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

Strings: double versus single quotes

[Manfred Lotz]

Hi there,
I am asking myself if I should preferably use single or double quotes
for strings?

If I need a single quote in a string I would use double quotes for the
whole string and vice versa. For f-strings I mostly see double
quotes but single quotes would work as well I think.

Is there a recommendation?


-- 
Manfred
 


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

RE: why no camelCase in PEP 8?

[Schachner, Joseph]

I don't actually know, but I can take a guess.  CamelCase can be problematic 
with terms that are abbreviations and always upper case.  For example FIRFilter 
or USBPLL
The first violated camelCase because it has no lower case letters before 
Filter, and the second completely violates camelCase because both USB and PLL 
are well known always capitalized abbreviations so that name has no lower case 
letters.

On the other hand FIR_filter and USB_PLL have no problem showing where the 
split should be.

And, because '_' looks sort of like a space, the individual words are more 
easily readable.  notEveyoneThinksReadingCamelCaseIsEasy.

-- Joseph S.

-Original Message-
From: Lance E Sloan  
Sent: Monday, May 18, 2020 3:47 PM
To: python-list@python.org
Subject: why no camelCase in PEP 8?

I've been using Python for about 18 years.  Several things have changed in the 
language in those years.  I don't disagree with most of it, but one of the 
things that annoys me is the disapproval of using camelCase to name symbols 
such as variables, functions, etc.

I think PEP 8, the "Style Guide for Python Code" 
(https://www.python.org/dev/peps/pep-0008/), came out shortly after I began 
using Python.  I think the old habits of the people I worked with and the 
relative lack of tools like Flake8 and Pylint led to the standard being 
ignored.  However, now I see many developers really want to adhere to the 
standard.

My preference for using camelCase (in PEP 8, AKA mixedCase) is putting me at 
odds with my colleagues, who point to PEP 8 as "the rules".  I have reasons for 
my preferring camelCase.  I suspect the reasons the PEP 8 authors have for not 
using it are probably as strong as my reasons.  So our reasons probably nullify 
each other and what's left is simple preference.

So, I'd like to know what was the reason behind favoring snake_case (AKA 
lower_case_with_underscores) in PEP 8 instead of camelCase.

Does anyone in this group know?

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

Re: why no camelCase in PEP 8?

[Richard Damon]

On 5/19/20 4:02 AM, Barry Scott wrote:
>
>> On 18 May 2020, at 22:07, Eli the Bearded <*@eli.users.panix.com> wrote:
>>
>>  camelCase   ->   noCamelCase
>>  snake_case  ->   no_snake_case
>>
>> One of those is easier to "grep" for than the other.
> I guess you mean that a case-sensitive grep can tell
> camelCase from noCamelCase.
>
> In all cases you need to use a \b to mark the boundary of the word.
> Otherwise the RE will match more than you expect, assuming a
> large set of identifiers.
>
> grep '\bsnake_case\b *.py
>
> Barry
>
I think the issue is that you can easy search for all 'snake_case' and
get them, but you have more difficulty searching for all 'camelCase',
needing to go case insensitive, but if leading case matters (like there
is a type CamelCase that you don't want) you get unwanted hits.

-- 
Richard Damon

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

[RELEASE] Python 3.9.0b1 is now available for testing

[Łukasz Langa]

On behalf of the entire Python development community, and the currently serving 
Python release team in particular, I’m pleased to announce the release of 
Python 3.9.0b1. Get it here:

https://www.python.org/downloads/release/python-390b1/ 


This is a beta preview of Python 3.9

Python 3.9 is still in development. This release, 3.9.0b1, is the first of four 
planned beta release previews.

Beta release previews are intended to give the wider community the opportunity 
to test new features and bug fixes and to prepare their projects to support the 
new feature release.

Call to action

We strongly encourage maintainers of third-party Python projects to test with 
3.9 during the beta phase and report issues found to the Python bug tracker 
 as soon as possible. While the release is planned to 
be feature complete entering the beta phase, it is possible that features may 
be modified or, in rare cases, deleted up until the start of the release 
candidate phase (2020-08-10). Our goal is have no ABI changes after beta 4 and 
as few code changes as possible after 3.9.0rc1, the first release candidate. To 
achieve that, it will be extremely important to get as much exposure for 3.9 as 
possible during the beta phase.

Please keep in mind that this is a preview release and its use is not 
recommended for production environments.

Major new features of the 3.9 series, compared to 3.8

Some of the new major new features and changes in Python 3.9 are:

PEP 584 , Union Operators in dict

PEP 585 , Type Hinting Generics In 
Standard Collections

PEP 593 , Flexible function and 
variable annotations

PEP 602 , Python adopts a stable 
annual release cadence

PEP 616 , String methods to remove 
prefixes and suffixes

PEP 617 , New PEG parser for CPython

BPO 38379 , garbage collection does not 
block on resurrected objects;

BPO 38692 , os.pidfd_open added that allows 
process management without races and signals;

BPO 39926 , Unicode support updated to 
version 13.0.0;

BPO 1635741 , when Python is initialized 
multiple times in the same process, it does not leak memory anymore;

A number of Python builtins (range, tuple, set, frozenset, list, dict) are now 
sped up using PEP 590  vectorcall;

A number of Python modules (_abc, audioop, _bz2, _codecs, _contextvars, _crypt, 
_functools, _json, _locale, operator, resource, time, _weakref) now use 
multiphase initialization as defined by PEP 489 
;

A number of standard library modules (audioop, ast, grp, _hashlib, pwd, 
_posixsubprocess, random, select, struct, termios, zlib) are now using the 
stable ABI defined by PEP 384 .

(Hey, fellow core developer, if a feature you find important is missing from 
this list, let Łukasz know .)

The next pre-release, the second beta release of Python 3.9, will be 3.9.0b2. 
It is currently scheduled for 2020-06-08.

More resources

Online Documentation 
PEP 596 , 3.9 Release Schedule
Report bugs at https://bugs.python.org .
Help fund Python and its community .
Your friendly release team,
Ned Deily @nad 
Steve Dower @steve.dower 
Łukasz Langa @ambv 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Subprocess Popen confusion

[Barry Scott]

> On 18 May 2020, at 21:50, Dick Holmes  wrote:

snip

> Per Peter's suggestion I tried readline and it works "as expected". I 
> also discovered that the reason the read operations were stalling was 
> that they followed a write and the write doesn't actually occur until 
> "flush" is called even though the function call returns. There are 
> undoubtedly some subtleties lurking about, but at least I'm making good 
> progress.

You need the flush() because the stream is using buffered I/O.

Each write adds to the buffer inside python and when then buffer if full it is
written out of Python into the OS.

As you found you can force a partial buffer to be written by calling flush().

Barry


> 
> Thanks for the help!
> 
> Dick
> 
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list 
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: why no camelCase in PEP 8?

[Rhodri James]

On 18/05/2020 22:07, Eli the Bearded wrote:

camelCase   ->noCamelCase
snake_case  ->no_snake_case

One of those is easier to "grep" for than the other.


Eh.  A changed case in the one, an extra character in the other; that's 
pretty much the same difficulty really.  I certainly don't find it 
"hard" to grep for _snake_case.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: why no camelCase in PEP 8?

[Barry Scott]

> On 18 May 2020, at 22:07, Eli the Bearded <*@eli.users.panix.com> wrote:
> 
>   camelCase   ->   noCamelCase
>   snake_case  ->   no_snake_case
> 
> One of those is easier to "grep" for than the other.

I guess you mean that a case-sensitive grep can tell
camelCase from noCamelCase.

In all cases you need to use a \b to mark the boundary of the word.
Otherwise the RE will match more than you expect, assuming a
large set of identifiers.

grep '\bsnake_case\b *.py

Barry

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