Re: stderr writting before stdout

[Souvik Dutta]

Thank you I understood. Sorry for top posting... 😛


On Sun, 24 May, 2020, 11:34 am Cameron Simpson,  wrote:

> Please don't top post; I have rearranged your message so that the
> discussion reads from top to bottom. Reponse below.
>
> On 24May2020 10:04, Souvik Dutta  wrote:
> >On Sun, 24 May, 2020, 9:57 am Souvik Dutta, 
> >wrote:
> >> Is there any precedence or priority order by which sys.stderr.write()
> >> and
> >> sys.stdout.write() works. Because when running the below code...
> >>
> >> import sys
> >> sys.stdout.write("Writting")
> >> sys.stderr.write("No errors \n")
> >>
> >> No errors is written (displayed) first and writting is written later.
> Why
> >> does this happen?
> >
> >Also this code maintains order i.e. writting is displayed before no
> >errors.
> >Why is that?
> >
> >import sys
> >sys.stdout.write("Writting \n")
> >sys.stderr.write("No errors \n")
>
> This is all to do with buffering.
>
> Output streams are buffered (unless you go out of your way to avoid it).
> This means that for throughput performance reasons, when you go
> f.write(...) the daa are written into an in memory buffer, and not yet
> to the file itself. The buffer is conventionally of fixe size.
>
> A fully buffered stream tries to minimise the OS-write calls (which copy
> from the pogramme to the operating system) because they are
> comparitively expensive. For thorughtput, writing a lot of data in bulk,
> this is a win because the OS-write calls are as few as possibly.
>
> An unbuffered stream calls the OS-write as soon as any data are
> received; there wouldn't even be an in memory beffer at all. This
> presents data to the OS as soon as possible, at the cost of more frequnt
> OS-write calls.
>
> In between these 2 extremes are onther policies. One such is line
> buffering: the contents of the buffer are written to the OS when there
> is a complete line in the bufeer (i.e. when a newline character arrives
> in the data). This is common on terminals, and writes complete lines to
> the terminal. This is common for writing "text" to a terminal, and makes
> more OS-writes that full buffeing and fewer than unbuffered as a
> comprimise to present timely display to a human.
>
> You can force an OS-write of a buffered stream by calling its flush()
> method.
>
> Conventionally, on UNIX systems, an output stream connected to a regular
> file is fully buffered, to maximise bulk data writing throughput. An
> output stream connected to a terminal is line buffered. Except for
> stderr, which is _unbuffered_ because it is felt that error messages
> should always show up as soon as possible.
>
> These different policies explain the behaviour you see.
>
> By inserting:
>
> sys.stdout.flush()
>
> calls at various points for can force OS-write calls and see data
> immediately, which will make this more clear to you.
>
> Cheers,
> Cameron Simpson 
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: stderr writting before stdout

[Cameron Simpson]

Please don't top post; I have rearranged your message so that the 
discussion reads from top to bottom. Reponse below.


On 24May2020 10:04, Souvik Dutta  wrote:
On Sun, 24 May, 2020, 9:57 am Souvik Dutta,  
wrote:
Is there any precedence or priority order by which sys.stderr.write() 
and

sys.stdout.write() works. Because when running the below code...

import sys
sys.stdout.write("Writting")
sys.stderr.write("No errors \n")

No errors is written (displayed) first and writting is written later. Why
does this happen?


Also this code maintains order i.e. writting is displayed before no 
errors.

Why is that?

import sys
sys.stdout.write("Writting \n")
sys.stderr.write("No errors \n")


This is all to do with buffering.

Output streams are buffered (unless you go out of your way to avoid it).  
This means that for throughput performance reasons, when you go 
f.write(...) the daa are written into an in memory buffer, and not yet 
to the file itself. The buffer is conventionally of fixe size.


A fully buffered stream tries to minimise the OS-write calls (which copy 
from the pogramme to the operating system) because they are 
comparitively expensive. For thorughtput, writing a lot of data in bulk, 
this is a win because the OS-write calls are as few as possibly.


An unbuffered stream calls the OS-write as soon as any data are 
received; there wouldn't even be an in memory beffer at all. This 
presents data to the OS as soon as possible, at the cost of more frequnt 
OS-write calls.


In between these 2 extremes are onther policies. One such is line 
buffering: the contents of the buffer are written to the OS when there 
is a complete line in the bufeer (i.e. when a newline character arrives 
in the data). This is common on terminals, and writes complete lines to 
the terminal. This is common for writing "text" to a terminal, and makes 
more OS-writes that full buffeing and fewer than unbuffered as a 
comprimise to present timely display to a human.


You can force an OS-write of a buffered stream by calling its flush() 
method.


Conventionally, on UNIX systems, an output stream connected to a regular 
file is fully buffered, to maximise bulk data writing throughput. An 
output stream connected to a terminal is line buffered. Except for 
stderr, which is _unbuffered_ because it is felt that error messages 
should always show up as soon as possible.


These different policies explain the behaviour you see.

By inserting:

   sys.stdout.flush()

calls at various points for can force OS-write calls and see data 
immediately, which will make this more clear to you.


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

Re: Strings: double versus single quotes

[Frank Millman]

On 2020-05-23 9:45 PM, DL Neil via Python-list wrote:


My habit with SQL queries is to separate them from other code, cf the 
usual illustration of having them 'buried' within the code, immediately 
before, or even part of, the query call.




I like that idea, as I find that I am embedding more and more SQL in my 
code.


How do you handle parameters? Do you leave placeholders ('?' or '%s') in 
the query, and leave it to the 'importer' of the query to figure out 
what is required?


Frank Millman


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

Re: Strings: double versus single quotes

[Abdur-Rahmaan Janhangeer]

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy  | blog

github 
Mauritius


On Sun, May 24, 2020 at 12:03 AM DL Neil via Python-list <
python-list@python.org> wrote:

>
> I'm highly amused by this interchange - for two reasons: that you'd
> noticed these details, and that I hadn't!
>

Yes Mr Chris is good for coming on with these kind of points ^^_


>
> Yes, I'd noted that the REPL responds with single-quotes, even if I used
> double-quotes in the definition (per "single of double", above) - for
> whatever that's worth (it's not as if the delimiters are stored along
> with other variable detail!)
>
> That the REPL is 'intelligent' about its choice to vary the delimiter to
> suit the content is good (design) sense - the best presentation (UX), ie
> doesn't is a better presentation than doesn\'t!
>
> Which brings me to my own, humble, and quite often non-PEP-8-respecting
> habits: that I (basically) apply the ?rules of English grammar to Python
> (which I write (mostly) in English). Thus a "quotation", eg someone's
> name, but any piece of data, will be enclosed in double-quotes:
>
> name = "Abdur-Rahman"
>
> whereas, when something will be 'calculated', I use singles, eg
>
> f'{ name } is top of the class'
>

This discussion dives a bit further into the philosophy
of Python.  Must reactivate the FaQ repo project.
Mr Barker is doing it for python-ideas.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

[Abdur-Rahmaan Janhangeer]

Greetings,

Nice idea

>>> '''You said "No it doesn't"'''
'You said "No it doesn\'t"'

Kind Regards,

Abdur-Rahmaan Janhangeer
compileralchemy  | blog

github 
Mauritius


On Sun, May 24, 2020 at 9:05 AM Manfred Lotz  wrote:

> On Sat, 23 May 2020 14:46:04 -0400
> Dennis Lee Bieber  wrote:
>
> > On Sat, 23 May 2020 11:03:09 -0500, Tim Chase
> >  declaimed the following:
> >
> >
> > >
> > >But when a string contains both, it biases towards single quotes:
> > >
> > >   >>> "You said \"No it doesn't\""
> > >   'You said "No it doesn\'t"'
> >
> >   This is where using triple quotes (or triple apostrophes)
> > around the entire thing simplifies it all... (except for a need to
> > separate the four ending quotes)
>
> Exactly, I also would opt for triple quotes in this case.
>
> >
> > >>> """You said "No it doesn't" """
> > 'You said "No it doesn\'t" '
> > >>> '''You said "No it doesn't"'''
> > 'You said "No it doesn\'t"'
> > >>>
> >
> >   NO \ escapes needed on the input strings.
> >
> > >>> print("""You said "No it doesn't" """)
> > You said "No it doesn't"
> > >>> print('''You said "No it doesn't"''')
> > You said "No it doesn't"
> > >>>
> >
> >
>
>
> --
> Manfred
>
> --
> 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 Sat, 23 May 2020 14:46:04 -0400
Dennis Lee Bieber  wrote:

> On Sat, 23 May 2020 11:03:09 -0500, Tim Chase
>  declaimed the following:
> 
> 
> >
> >But when a string contains both, it biases towards single quotes:
> >  
> >   >>> "You said \"No it doesn't\""  
> >   'You said "No it doesn\'t"'  
> 
>   This is where using triple quotes (or triple apostrophes)
> around the entire thing simplifies it all... (except for a need to
> separate the four ending quotes)

Exactly, I also would opt for triple quotes in this case. 

> 
> >>> """You said "No it doesn't" """  
> 'You said "No it doesn\'t" '
> >>> '''You said "No it doesn't"'''  
> 'You said "No it doesn\'t"'
> >>>   
> 
>   NO \ escapes needed on the input strings.
> 
> >>> print("""You said "No it doesn't" """)  
> You said "No it doesn't" 
> >>> print('''You said "No it doesn't"''')  
> You said "No it doesn't"
> >>>   
> 
> 


-- 
Manfred

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

Re: stderr writting before stdout

[Souvik Dutta]

Also this code maintains order i.e. writting is displayed before no errors.
Why is that?

import sys
sys.stdout.write("Writting \n")
sys.stderr.write("No errors \n")

On Sun, 24 May, 2020, 9:57 am Souvik Dutta,  wrote:

> Hi,
> Is there any precedence or priority order by which sys.stderr.write() and
> sys.stdout.write() works. Because when running the below code...
>
> import sys
> sys.stdout.write("Writting")
> sys.stderr.write("No errors \n")
>
> No errors is written (displayed) first and writting is written later. Why
> does this happen?
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Enums are Singletons - but not always?

[Terry Reedy]

On 5/23/2020 2:21 PM, Ralf M. wrote:


# Code of mod1.py #
import enum, mod2
class En(enum.Enum):
     A = 1
     B = 2
def main():
     a = mod2.getA()
     print("a is En.A:", a is En.A)
     print("a:", repr(a), "    En.A:", repr(En.A))
     print("id(a), id(a.__class__)", id(a), id(a.__class__))
     print("id(En.A), id(En)  ", id(En.A), id(En))
if __name__ == "__main__":
     main()


> # Code of mod2.py #
> import mod1
> def getA():
> return mod1.En.A

As a couple of people mentioned, the issue is the circular import.  When 
you run mod1 from a command line, its name is __main__.  Its execution 
of mod1 code stops to execute enum code and then mod2 code.


Execution of mod2 stops to execute mod1 code in a new module named 
'mod1'.  When the second execution of mod1 code does the import of enum 
and mod2, sys.modules['enum'] and sys.modules['mod2'] exist, are found, 
and used to satify the import.  So enum and mod2 code are not executed 
again.  In the 'mod1' module, 'mod2' is linked to the *incomplete* mod2. 
 This 'works' in your code because the reference to mod2 within def 
main is not used because the name is 'mod1', not '__main__'.  But if in 
mod1, you had written


import enum
from mod2 import getA

the second execution of mod1 would fail because mod2.getA does not exist 
because execution of mod2 is paused to import mod1


When the mod1 import in mod2 finishes, the execution of mod2 code for 
'mod2' finishes without issue.  Then the execution of 'mod1' code in 
'__main__' finishes with the call to main.


When you instead interactively import mod1, it is executed just once and 
you have to explicitly call main.


In idlelib, pyshell currently has the IDLE Shell code, the main() 
function, and a couple of classes used elsewhere.  (An atrocious design 
that I inherited and have only partly fixed.)  As a *temporary* fix to 
an issue due to there being  duplicate '__main__' and 'pyshell' modules, 
I added the following to the top of pyshell.


import sys
if __name__ == "__main__":
sys.modules['idlelib.pyshell']=sys.modules['__main__']

But doing what others suggested, limiting the main or start module to 
one-time code, is better.



--
Terry Jan Reedy


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

Re: Strings: double versus single quotes

[Souvik Dutta]

This seems to be a life long debate...

On Sun, 24 May, 2020, 5:25 am Tim Chase, 
wrote:

> On 2020-05-23 14:46, Dennis Lee Bieber wrote:
> > On Sat, 23 May 2020 11:03:09 -0500, Tim Chase
> > >But when a string contains both, it biases towards single quotes:
> > >
> > >   >>> "You said \"No it doesn't\""
> > >   'You said "No it doesn\'t"'
> >
> >   This is where using triple quotes (or triple apostrophes)
> > around the entire thing simplifies it all... (except for a need to
> > separate the four ending quotes)
>
> Unless you're pathological. ;-)
>
> >>> """I said "This contain every type of \"""Python\"""
> '''triple-quoted''' string, doesn't it?\
> 'I said "This contains every type of """Python"""
> \'\'\'triple-quoted\'\'\' string, doesn\'t it."'
>
> And-you-can-quote-me-on-that'ly yers,
>
> -tkc
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

[Tim Chase]

On 2020-05-23 14:46, Dennis Lee Bieber wrote:
> On Sat, 23 May 2020 11:03:09 -0500, Tim Chase
> >But when a string contains both, it biases towards single quotes:
> >  
> >   >>> "You said \"No it doesn't\""  
> >   'You said "No it doesn\'t"'  
> 
>   This is where using triple quotes (or triple apostrophes)
> around the entire thing simplifies it all... (except for a need to
> separate the four ending quotes)

Unless you're pathological. ;-)

>>> """I said "This contain every type of \"""Python\""" '''triple-quoted''' 
>>> string, doesn't it?\
'I said "This contains every type of """Python""" \'\'\'triple-quoted\'\'\' 
string, doesn\'t it."'

And-you-can-quote-me-on-that'ly yers,

-tkc



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

Re: Strings: double versus single quotes

[DL Neil via Python-list]

On 24/05/20 8:39 AM, Skip Montanaro wrote:



May I ask why not simply like this:

stmt = """
   select foo from bar
 where a = 'bag'
   and c = 'dog'
   """


Sorry, I don't recall. I wouldn't be at all surprised that it has something
to do with Emacs's Python mode behavior. Emacs wouldn't know what to do
with spaces in the string, but knows where to put string literals within
the open parens. I'm pretty sure I was doing this before triple quoted
strings existed.

Thankfully, I don't need to mess around with SQL anymore. :-)


A. don't be like that - send it all to me, and I'll fix it for you 
(at exorbitant rates, of course)...



The above is valid - the editor has a file in one format/language, and 
is therefore applying 'the wrong rules' when it attempts to make SQL 
look like Python!



The inconvenience (cf "issue") that arises, is that many SQL debuggers 
and error-handlers (etc) will repeat-back the source-code/query 
as-provided. Consequently, those messages are all messed-up with 
extraneous tabs and new-lines, making them difficult to read and debug.

(see also: earlier post mentioning separation of languages/code)
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: installed but doesn't boot

[DL Neil via Python-list]

On 24/05/20 4:55 AM, Ben Hansen wrote:

-- Forwarded message -
From: Ben Hansen 
Date: Sat, May 23, 2020 at 11:44 AM
Subject: Fwd: installed but doesn't boot
To: 




-- Forwarded message -
From: Ben Hansen 
Date: Fri, May 22, 2020 at 3:18 PM
Subject: installed but doesn't boot
To: 


I have installed python after getting the book "Coding for Kids/Python, and
it won't boot.  HELP



Assuming MS-Windows:
Please advise if the following reference is accurate, and works for you:
https://docs.python.org/3/using/windows.html
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

[Skip Montanaro]

>
>
> May I ask why not simply like this:
>
> stmt = """
>   select foo from bar
> where a = 'bag'
>   and c = 'dog'
>   """
>

Sorry, I don't recall. I wouldn't be at all surprised that it has something
to do with Emacs's Python mode behavior. Emacs wouldn't know what to do
with spaces in the string, but knows where to put string literals within
the open parens. I'm pretty sure I was doing this before triple quoted
strings existed.

Thankfully, I don't need to mess around with SQL anymore. :-)

Skip

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

Re: Enums are Singletons - but not always?

[Roel Schroeven]

Richard Damon schreef op 23/05/2020 om 20:57:

On 5/23/20 2:21 PM, Ralf M. wrote:

Hello,

recently I wrote a small library that uses an Enum. That worked as
expected. Then I added a main() and if __name__ == "__main__" to make
it runable as script. Now Enum members that should be the same aren't
identical any more, there seem to be two instances of the same Enum.

I think I know what's going on, but cannot find a good and elegant way
to avoid the problem. I hope someone here can help me there.


I don;'t think Python anywhere defines that a enum will be a singleton,
and you should be checking for equality (==) not identity (is)


So much this. Always check for equality instead of identity, unless you 
know what you're doing and you have a very good reason to use identity.


Everywhere I see questions all the time from people new to Python, 
confused about stuff that happens when comparing using identity. I would 
like to know where that comes from ... are there tutorials that 
encourage using identity checks?


--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

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

Subject: Python Open-Source Snippets Newsletter

[Aswin K]

Hi,

I am creating a Python newsletter showcasing useful code snippets from 
popular open-source libraries. I will also be providing a runnable demo 
link to better understand the working.


Newsletter subscription link: https://www.pythonninja.xyz/subscribe

A sample snippet from the newsletter:

HTTP Request retrying with Backoffs - Technique for retrying failed HTTP 
requests.


From Google Maps Services Python 
(https://github.com/googlemaps/google-maps-services-python)


Demo link: https://repl.it/@PythonNinja/requestretries

"""
first_request_time: The time of the first request (None if no retries 
have occurred).

retry_counter: The count of retries, or zero for the first attempt.
"""

if not first_request_time:
first_request_time = datetime.now()

elapsed = datetime.now() - first_request_time
if elapsed > self.retry_timeout:
raise googlemaps.exceptions.Timeout()

if retry_counter > 0:
# 0.5 * (1.5 ^ i) is an increased sleep time of 1.5x per iteration,
# starting at 0.5s when retry_counter=0. The first retry will occur
# at 1, so subtract that first.
delay_seconds = 0.5 * 1.5 ** (retry_counter - 1)

# Jitter this value by 50% and pause.
time.sleep(delay_seconds * (random.random() + 0.5))

Subscribe here: https://www.pythonninja.xyz/subscribe

Feedbacks and criticism are welcome.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

[Roel Schroeven]

Skip Montanaro schreef op 23/05/2020 om 13:03:

I also agree about SQL. I found that something like this:

stmt = (
 """select foo from bar"""
 """  where a = 'bag'"""
 """and c = 'dog'"""
)

worked pretty well, served to both satisfy my brain's desire for semantic
indentation (you should see some of the SQL I inherited - yikes!) and
maintain a visual distinction between Python and SQL quoting. (Consistently
using triple quotes minimizes the chance of needing a stray Python
backslash inside the SQL code.)


May I ask why not simply like this:

stmt = """
 select foo from bar
   where a = 'bag'
 and c = 'dog'
 """

This introduces more newlines and spaces in the query, but that
shouldn't really matter. I think it's more readable, and easier to edit
the query.


I'm now retired, so can't double check, but
I believe SQLite and MSSQL are unusual in their Pythonesque treatment of
single and double quotes being synonymous. I believe most other dialects
(Oracle, MySQL, Sybase, PostgreSQL that I checked) only recognize single
quotes as string delimiters.


Right. The SQLite developers did it that way in an effort to be
compatible with MySQL, and since have come to the realisation that that
was a mistake. In recent versions you can turn it off, in which cases
single quotes are for string literals and double quotes are for
identifiers (such as column names), as in standard SQL.
See
https://sqlite.org/quirks.html#double_quoted_string_literals_are_accepted

--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
 -- Franklin P. Jones

Roel Schroeven



--
"Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger."
-- Franklin P. Jones

Roel Schroeven

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

Fwd: installed but doesn't boot

[Ben Hansen]

-- Forwarded message -
From: Ben Hansen 
Date: Sat, May 23, 2020 at 11:44 AM
Subject: Fwd: installed but doesn't boot
To: 




-- Forwarded message -
From: Ben Hansen 
Date: Fri, May 22, 2020 at 3:18 PM
Subject: installed but doesn't boot
To: 


I have installed python after getting the book "Coding for Kids/Python, and
it won't boot.  HELP
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Enums are Singletons - but not always?

[Ethan Furman]

On 05/23/2020 11:57 AM, Richard Damon wrote:


I don't think Python anywhere defines that a enum will be a singleton,
and you should be checking for equality (==) not identity (is)


If you're not sure, please do a little research first.  We have enough bad 
information on the 'nets already.

According to Kushal's link:


The most interesting thing about Enum members is that they are singletons.


The only time using `==` is necessary is for mixed-Enums, such as IntEnum, and 
you need to compare what could be an IntEnum member in code that could be using 
actual `int`s.

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

Re: Enums are Singletons - but not always?

[Chris Angelico]

On Sun, May 24, 2020 at 5:58 AM Kushal Kumaran  wrote:
>
> "Ralf M."  writes:
>
> > Below are a simplified code sample, the results when I run it and my
> > thoughts.
> >
> > # Code of mod1.py #
> > import enum, mod2
> > def main():
> > a = mod2.getA()
> > # End of mod1.py #
> >
> > # Code of mod2.py #
> > import mod1
> > def getA():
> > return mod1.En.A
> > # End of mod2.py #
> >
> I think of circular dependencies as a code smell.  You can move the enum
> definition into a separate module, and have both mod1 and mod2 import
> that, or like you say, by moving the main function into its own module.
> Maybe you can explain why you don't want this.

Correct - and especially since you're using the main module also as a
module. Currently, that is something you just plain shouldn't do. You
end up with one copy of the module called __main__ and another one
called mod1, and they're completely independent. Just don't do that.

However, there HAVE been some proposals to make this sort of thing
work. In general, they'd end up doing something like having the module
inserted into sys.modules twice, once as __main__ and once as mod1, so
you end up getting the same module in both cases. That would work,
since (with only one module) there'd only be one En class. I don't
think any such proposal has gotten fully serious yet, but if this is
something you're interested in (or feel strongly about), dig through
the python-ideas archives to see some of the arguments for and
against.

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

Re: Strings: double versus single quotes

[DL Neil via Python-list]

On 24/05/20 4:03 AM, Tim Chase wrote:

On 2020-05-24 01:40, Chris Angelico wrote:

On Sat, May 23, 2020 at 10:52 PM Abdur-Rahmaan Janhangeer
 wrote:


The interpreter prefers single-quotes
  

"single or double"

'single or double'
  

'not all that strongly, it doesn\'t'

"not all that strongly, it doesn't"


But when a string contains both, it biases towards single quotes:

>>> "You said \"No it doesn't\""
'You said "No it doesn\'t"'

;-)



I'm highly amused by this interchange - for two reasons: that you'd 
noticed these details, and that I hadn't!


Yes, I'd noted that the REPL responds with single-quotes, even if I used 
double-quotes in the definition (per "single of double", above) - for 
whatever that's worth (it's not as if the delimiters are stored along 
with other variable detail!)


That the REPL is 'intelligent' about its choice to vary the delimiter to 
suit the content is good (design) sense - the best presentation (UX), ie 
doesn't is a better presentation than doesn\'t!


Which brings me to my own, humble, and quite often non-PEP-8-respecting 
habits: that I (basically) apply the ?rules of English grammar to Python 
(which I write (mostly) in English). Thus a "quotation", eg someone's 
name, but any piece of data, will be enclosed in double-quotes:


name = "Abdur-Rahman"

whereas, when something will be 'calculated', I use singles, eg

f'{ name } is top of the class'

Never learning a language which distinguishes single character literals 
from strings, eg the C examples quoted earlier, such 
thoughts/distinctions don't 'exist'.
(which makes me wonder why code reviews have never queried the point, or 
registered that I might seem to be behaving inconsistently...)

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

Re: Enums are Singletons - but not always?

[Kushal Kumaran]

"Ralf M."  writes:

> Hello,
>
> recently I wrote a small library that uses an Enum. That worked as
> expected. Then I added a main() and if __name__ == "__main__" to make
> it runable as script. Now Enum members that should be the same aren't
> identical any more, there seem to be two instances of the same Enum.
>
> I think I know what's going on, but cannot find a good and elegant way
> to avoid the problem. I hope someone here can help me there.
>
> Below are a simplified code sample, the results when I run it and my
> thoughts.
>
> # Code of mod1.py #
> import enum, mod2
> class En(enum.Enum):
> A = 1
> B = 2
> def main():
> a = mod2.getA()
> print("a is En.A:", a is En.A)
> print("a:", repr(a), "En.A:", repr(En.A))
> print("id(a), id(a.__class__)", id(a), id(a.__class__))
> print("id(En.A), id(En)  ", id(En.A), id(En))
> if __name__ == "__main__":
> main()
> # End of mod1.py #
>
> # Code of mod2.py #
> import mod1
> def getA():
> return mod1.En.A
> # End of mod2.py #
>
> # Results when run: #
> C:\tmp>py mod1.py
> a is En.A: False
> a:  En.A: 
> id(a), id(a.__class__) 33305864 7182808
> id(En.A), id(En)   33180552 7183752
>
> C:\tmp>py
> Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC
> v.1916 64 bit
> (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
 import mod1
 mod1.main()
> a is En.A: True
> a:  En.A: 
> id(a), id(a.__class__) 49566792 44574280
> id(En.A), id(En)   49566792 44574280

>
> So: When run as script there are two instances of En (different ids),
> but when mod1 is imported and mod1.main() is run it works as expected
> (just one instance of En, same ids).
> BTW: py -m mod1 doesn't work either.
>
> What I thing is happening:
> When the script is run, mod1.py is executed and an instance of En and
> its members is created. During the same run mod1 is also imported (via
> mod2), the file mod1.py is executed again as part of the import and
> another, different instance of En and its members is created.
>
> How do I have to change mod1.py to avoid the problem?
> Currently I have moved main() into a new file script.py. That works,
> but is not what I wanted.
>

I think of circular dependencies as a code smell.  You can move the enum
definition into a separate module, and have both mod1 and mod2 import
that, or like you say, by moving the main function into its own module.
Maybe you can explain why you don't want this.

The note in the documentation about enum members being singletons only
applies to the members.  It does not apply to the enum class itself.  In
your case, __main__.En is not the same as mod1.En.  The members being
singleton means that, for the same enum class En, En.A will refer to the
same object as En(1), or, perhaps an unpickled object that has the same
value.

> I doubt it's a bug in the enum module, but should that be the case,
> I'm willing to open an issue on the bug tracker.
>
> Or can nothing be done about it?
>

It is not specific to the Enum class.  You'll see the same behaviour
with any class that gets imported under two different module names.

> Looking forward to any ideas
> Ralf M.
>
> P.S.:
> As I was about to send this post the following modification occured to
> me (see below). It works, but it doesn't feel right to import a module
> directly from inside itself.
> # Modified code of mod1.py (one line added) #
> import enum, mod2
> class En(enum.Enum):
> A = 1
> B = 2
> from mod1 import En  # NEW LINE, overwrite just defined En
> def main():
> a = mod2.getA()
> print("a is En.A:", a is En.A)
> print("a:", repr(a), "En.A:", repr(En.A))
> print("id(a), id(a.__class__)", id(a), id(a.__class__))
> print("id(En.A), id(En)  ", id(En.A), id(En))
> if __name__ == "__main__":
> main()

I agree this is unpleasant to read.

-- 
regards,
kushal
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Enums are Singletons - but not always?

[Peter Otten]

Peter Otten wrote:

>> # Code of mod2.py #
> import __main__ as mod1
>> def getA():
>>return mod1.En.A
>> # End of mod2.py #
> 
> but that would hardcode the assumption that __main__ is always mod1.py.

I should have mentioned the cyclic dependency -- if two modules import each 
other one may not be completely set up when the other tries to access it.


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

Re: Enums are Singletons - but not always?

[Kushal Kumaran]

Richard Damon  writes:

> On 5/23/20 2:21 PM, Ralf M. wrote:
>> Hello,
>>
>> recently I wrote a small library that uses an Enum. That worked as
>> expected. Then I added a main() and if __name__ == "__main__" to make
>> it runable as script. Now Enum members that should be the same aren't
>> identical any more, there seem to be two instances of the same Enum.
>>
>> I think I know what's going on, but cannot find a good and elegant way
>> to avoid the problem. I hope someone here can help me there.
>
> I don;'t think Python anywhere defines that a enum will be a singleton,
> and you should be checking for equality (==) not identity (is)
>

https://docs.python.org/3/library/enum.html#enum-members-aka-instances

-- 
regards,
kushal
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

[DL Neil via Python-list]

On 23/05/20 11:03 PM, Skip Montanaro wrote:

I also agree about SQL. I found that something like this:

stmt = (
 """select foo from bar"""
 """  where a = 'bag'"""
 """and c = 'dog'"""
)

worked pretty well, served to both satisfy my brain's desire for semantic
indentation (you should see some of the SQL I inherited - yikes!) and
maintain a visual distinction between Python and SQL quoting. (Consistently
using triple quotes minimizes the chance of needing a stray Python
backslash inside the SQL code.) I'm now retired, so can't double check, but
I believe SQLite and MSSQL are unusual in their Pythonesque treatment of
single and double quotes being synonymous. I believe most other dialects
(Oracle, MySQL, Sybase, PostgreSQL that I checked) only recognize single
quotes as string delimiters.



The older (and more professional?) RDBMS accept either/both as variable 
delimiters, per Python strings.


My habit with SQL queries is to separate them from other code, cf the 
usual illustration of having them 'buried' within the code, immediately 
before, or even part of, the query call.


This partly because (a) some dev.teams have a specific person handling 
DBA-tasks, and partly (b) in order to make it easy to 
find/correct/re-factor SQL code without it being mixed-in with the Python.


(a) using a separate and specific module for SQL constants (which may 
include queries as text, or prepared queries), means that the 'DBA' may 
develop independently of the Python devs; that integration of code 
happens in the VCS; that the Python code may separate (stub) or 
integrate during unit-testing, according to progress and choice.


(b) physical 'extraction' and separation make it easier to develop and 
test each component (SQL, Python, ...) separately - either work in SQL 
*or* in Python, and not have the extra 'load' of having to flip one's 
brain between the two; and by using a separate module, makes it easy to 
locate a 'class' of code dealing with particular data and/or 
carrying-out particular functions - much as you might for classes and/or 
libraries.


Oh, and a further benefit: (further to "inherited", above) it becomes 
easier to avoid the massive tangles caused by trying to mix the 
conventions for indenting multi-line SQL code, with those for Python!

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

Re: Enums are Singletons - but not always?

[Peter Otten]

Ralf M. wrote:

> Hello,
> 
> recently I wrote a small library that uses an Enum. That worked as
> expected. Then I added a main() and if __name__ == "__main__" to make it
> runable as script. Now Enum members that should be the same aren't
> identical any more, there seem to be two instances of the same Enum.
> 
> I think I know what's going on, but cannot find a good and elegant way
> to avoid the problem. I hope someone here can help me there.
> 
> Below are a simplified code sample, the results when I run it and my
> thoughts.
> 
> # Code of mod1.py #
> import enum, mod2
> class En(enum.Enum):
>  A = 1
>  B = 2
> def main():
>  a = mod2.getA()
>  print("a is En.A:", a is En.A)
>  print("a:", repr(a), "En.A:", repr(En.A))
>  print("id(a), id(a.__class__)", id(a), id(a.__class__))
>  print("id(En.A), id(En)  ", id(En.A), id(En))
> if __name__ == "__main__":
>  main()
> # End of mod1.py #
> 
> # Code of mod2.py #
> import mod1
> def getA():
>  return mod1.En.A
> # End of mod2.py #
> 
> # Results when run: #
> C:\tmp>py mod1.py
> a is En.A: False
> a:  En.A: 
> id(a), id(a.__class__) 33305864 7182808
> id(En.A), id(En)   33180552 7183752
> 
> C:\tmp>py
> Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916
> 64 bit
> (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import mod1
>  >>> mod1.main()
> a is En.A: True
> a:  En.A: 
> id(a), id(a.__class__) 49566792 44574280
> id(En.A), id(En)   49566792 44574280
>  >>>
> 
> So: When run as script there are two instances of En (different ids),
> but when mod1 is imported and mod1.main() is run it works as expected
> (just one instance of En, same ids).
> BTW: py -m mod1 doesn't work either.
> 
> What I thing is happening:
> When the script is run, mod1.py is executed and an instance of En and
> its members is created. During the same run mod1 is also imported (via
> mod2), the file mod1.py is executed again as part of the import and
> another, different instance of En and its members is created.
> 
> How do I have to change mod1.py to avoid the problem?
> Currently I have moved main() into a new file script.py. That works, but
> is not what I wanted.

But that is exactly the right approach. Avoid importing the main script 
under its name because that will run all code that is not guarded by 

if __name__ == "__main__": ...

twice. In your case it's enum, but the same goes for every class, function 
or object and the module itself. In Python they are all created rather than 
declared.

> I doubt it's a bug in the enum module, but should that be the case, I'm
> willing to open an issue on the bug tracker.
> 
> Or can nothing be done about it?

mod2 could import the __main__ module, e. g. 

> # Code of mod2.py #
  import __main__ as mod1
> def getA():
>  return mod1.En.A
> # End of mod2.py #

but that would hardcode the assumption that __main__ is always mod1.py.

The only sane option is to not put anything in the main script that needs to 
be imported by other modules.

> Looking forward to any ideas
> Ralf M.
> 
> P.S.:
> As I was about to send this post the following modification occured to
> me (see below). It works, but it doesn't feel right to import a module
> directly from inside itself.
> # Modified code of mod1.py (one line added) #
> import enum, mod2
> class En(enum.Enum):
>  A = 1
>  B = 2
> from mod1 import En  # NEW LINE, overwrite just defined En
> def main():
>  a = mod2.getA()
>  print("a is En.A:", a is En.A)
>  print("a:", repr(a), "En.A:", repr(En.A))
>  print("id(a), id(a.__class__)", id(a), id(a.__class__))
>  print("id(En.A), id(En)  ", id(En.A), id(En))
> if __name__ == "__main__":
>  main()


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

Re: Is there some reason that recent Windows 3.6 releases don't included executable nor msi installers?

[Mats Wichmann]

On 5/23/20 12:23 AM, Adam Preble wrote:
> I wanted to update from 3.6.8 on Windows without necessarily moving on to 
> 3.7+ (yet), so I thought I'd try 3.6.9 or 3.6.10. 
> 
> All I see for both are source archives:
> 
> https://www.python.org/downloads/release/python-369/
> https://www.python.org/downloads/release/python-3610/
> 
> So, uh, I theoretically did build a 3.6.10 .exe installer, but I don't really 
> trust I did everything right. Is there an officially sourced installation?
> 

During the early part of a release cycle, installers are built.  Once
the cycle moves into security fix-only mode, installers are not built.
That's all you are seeing.

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

Re: Enums are Singletons - but not always?

[Richard Damon]

On 5/23/20 2:21 PM, Ralf M. wrote:
> Hello,
>
> recently I wrote a small library that uses an Enum. That worked as
> expected. Then I added a main() and if __name__ == "__main__" to make
> it runable as script. Now Enum members that should be the same aren't
> identical any more, there seem to be two instances of the same Enum.
>
> I think I know what's going on, but cannot find a good and elegant way
> to avoid the problem. I hope someone here can help me there.

I don;'t think Python anywhere defines that a enum will be a singleton,
and you should be checking for equality (==) not identity (is)

-- 
Richard Damon

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

Enums are Singletons - but not always?

[Ralf M.]

Hello,

recently I wrote a small library that uses an Enum. That worked as 
expected. Then I added a main() and if __name__ == "__main__" to make it 
runable as script. Now Enum members that should be the same aren't 
identical any more, there seem to be two instances of the same Enum.


I think I know what's going on, but cannot find a good and elegant way 
to avoid the problem. I hope someone here can help me there.


Below are a simplified code sample, the results when I run it and my 
thoughts.


# Code of mod1.py #
import enum, mod2
class En(enum.Enum):
A = 1
B = 2
def main():
a = mod2.getA()
print("a is En.A:", a is En.A)
print("a:", repr(a), "En.A:", repr(En.A))
print("id(a), id(a.__class__)", id(a), id(a.__class__))
print("id(En.A), id(En)  ", id(En.A), id(En))
if __name__ == "__main__":
main()
# End of mod1.py #

# Code of mod2.py #
import mod1
def getA():
return mod1.En.A
# End of mod2.py #

# Results when run: #
C:\tmp>py mod1.py
a is En.A: False
a:  En.A: 
id(a), id(a.__class__) 33305864 7182808
id(En.A), id(En)   33180552 7183752

C:\tmp>py
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 
64 bit

(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import mod1
>>> mod1.main()
a is En.A: True
a:  En.A: 
id(a), id(a.__class__) 49566792 44574280
id(En.A), id(En)   49566792 44574280
>>>

So: When run as script there are two instances of En (different ids), 
but when mod1 is imported and mod1.main() is run it works as expected 
(just one instance of En, same ids).

BTW: py -m mod1 doesn't work either.

What I thing is happening:
When the script is run, mod1.py is executed and an instance of En and 
its members is created. During the same run mod1 is also imported (via 
mod2), the file mod1.py is executed again as part of the import and 
another, different instance of En and its members is created.


How do I have to change mod1.py to avoid the problem?
Currently I have moved main() into a new file script.py. That works, but 
is not what I wanted.


I doubt it's a bug in the enum module, but should that be the case, I'm 
willing to open an issue on the bug tracker.


Or can nothing be done about it?

Looking forward to any ideas
Ralf M.

P.S.:
As I was about to send this post the following modification occured to 
me (see below). It works, but it doesn't feel right to import a module 
directly from inside itself.

# Modified code of mod1.py (one line added) #
import enum, mod2
class En(enum.Enum):
A = 1
B = 2
from mod1 import En  # NEW LINE, overwrite just defined En
def main():
a = mod2.getA()
print("a is En.A:", a is En.A)
print("a:", repr(a), "En.A:", repr(En.A))
print("id(a), id(a.__class__)", id(a), id(a.__class__))
print("id(En.A), id(En)  ", id(En.A), id(En))
if __name__ == "__main__":
main()
--
https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

[Abdur-Rahmaan Janhangeer]

Nice one,

Was requoting:

<>> "hello"
'hello'>>

from R Hettinger

Kind Regards,


Abdur-Rahmaan Janhangeer

https://www.github.com/Abdur-RahmaanJ

Mauritius

sent from gmail client on Android, that's why the signature is so ugly.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

[Tim Chase]

On 2020-05-24 01:40, Chris Angelico wrote:
> On Sat, May 23, 2020 at 10:52 PM Abdur-Rahmaan Janhangeer
>  wrote:
> >
> > The interpreter prefers single-quotes
> >  
> > >>> "single or double"  
> > 'single or double'
> >  
> >>> 'not all that strongly, it doesn\'t'  
> "not all that strongly, it doesn't"

But when a string contains both, it biases towards single quotes:

   >>> "You said \"No it doesn't\""
   'You said "No it doesn\'t"'

;-)

-tkc



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

Re: How to design a class that will listen on stdin?

[Dan Sommers]

On Saturday, May 23, 2020, at 07:24 -0400, zljubi...@gmail.com wrote:

> I have to talk to outer system by stdin/stdout.
> Each line that comes to stdin should be processed and its result returned 
> back to stdout. Logging should go to stderr.
> 
> How to design a class that will listed to stdin and call required methods in 
> order to process the data?

I wouldn't put it into a class, but the core of it looks something like
this:

for line in sys.stdin:
result = process(line)
print(result)
if some_condition():
break

The details may be different, and there's likely more error handling in
production code, but that's the general idea.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to design a class that will listen on stdin?

[Dieter Maurer]

zljubi...@gmail.com wrote at 2020-5-23 04:24 -0700:
>I have to talk to outer system by stdin/stdout.
>Each line that comes to stdin should be processed and its result returned back 
>to stdout. Logging should go to stderr.
>
>How to design a class that will listed to stdin and call required methods in 
>order to process the data?

Start by reading the Python tutorial
("https://docs.python.org/3/tutorial/index.html#tutorial-index";),
especially section 7.
-- 
https://mail.python.org/mailman/listinfo/python-list

How to design a class that will listen on stdin?

[zljubisic]

Hi,

I have to talk to outer system by stdin/stdout.
Each line that comes to stdin should be processed and its result returned back 
to stdout. Logging should go to stderr.

How to design a class that will listed to stdin and call required methods in 
order to process the data?

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

Re: exiting a while loop

[Grant Edwards]

On 2020-05-22, DL Neil via Python-list  wrote:
> On 23/05/20 4:31 AM, Grant Edwards wrote:
>> On 2020-05-22, Peter Otten <__pete...@web.de> wrote:
>> 
>>> If you want to terminate the script you can use exit. However exit
>>> is a function, and you have to call it
>>>
>>> exit()
>> 
>> 
>> 
>> Actually it's an instance of _sitebuiltins.Quitter not a function.
>> 
>> You still have to call it. ;)
>> 
>> 


> Which definition (may) make it 'worse' (when compared with "break"):

Oh, he definitely wanted break instead of exit(), and I assume the OP
had already taken that advice.

That's why I'm claiming extra pedant points: clarifying a pointless
detail about something the OP didn't want to be using in first place
and which had already been replaced by something else.

--
Grant






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

FlaskCon Call For Papers

[Abdur-Rahmaan Janhangeer]

Greetings list,

The call for papers for FlaskCon is open:
https://flaskcon.com/

It is a community-run event, 100% free and remote
with reviewers from the Pallets, Flask maintainers and
more

Feel free to pass the word around!

Kind Regards,

Abdur-Rahmaan Janhangeer
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exiting a while loop

[Terry Reedy]

On 5/22/2020 12:31 PM, Grant Edwards wrote:

On 2020-05-22, Peter Otten <__pete...@web.de> wrote:


If you want to terminate the script you can use exit. However exit
is a function, and you have to call it

exit()




Actually it's an instance of _sitebuiltins.Quitter not a function.


Which means that it is not part of the language and is not guaranteed to 
exist and will not if the local site module does not inject it.  quit() 
and exit() are only meant for interactive use at the >>> prompt as a 
cross-platform alternative to ^D or ^Z on non-Windows or Windows. 
They should not be used in programs unless explicitly defined or 
imported.  The reason both exist, violating the 'one obvious rule' is 
because both are (were) used used in various other REPLs and interactive 
text programs.



--
Terry Jan Reedy

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

Re: Strings: double versus single quotes

[Chris Angelico]

On Sat, May 23, 2020 at 10:52 PM Abdur-Rahmaan Janhangeer
 wrote:
>
> The interpreter prefers single-quotes
>
> >>> "single or double"
> 'single or double'
>
>>> 'not all that strongly, it doesn\'t'
"not all that strongly, it doesn't"

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

Re: Strings: double versus single quotes

[Abdur-Rahmaan Janhangeer]

The interpreter prefers single-quotes

>>> "single or double"
'single or double'

I read a recent quote from Raymond Hettinger saying that the
Python world prefers double ones. If Mr Hettinger is around i'd
like to ask him where he pulled the theory from
https://twitter.com/raymondh/status/1259209765072154624?s=20

Guess a personal choice thing ~

Kind Regards,

Abdur-Rahmaan Janhangeer
Mauritius


On Tue, May 19, 2020 at 10:20 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: Strings: double versus single quotes

[Rhodri James]

On 22/05/2020 20:57, Manfred Lotz wrote:

I also believe that transferring habits from C, Rust or whatever to
Python doesn't make much sense as Python does not distinguish between a
character and string from a type perspective.


From a logical perspective, you are correct.  From the point of view of 
someone who writes more C code than Python, not having to remember a new 
set of habits for Python makes life a lot simpler.


Chacun à son goût and all that.

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

Re: PyCharm, how to setup self contained subprojects

[zljubisic]

You are probably right.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strings: double versus single quotes

[Skip Montanaro]

> 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 also came to Python from C and tend to make the same mental distinction,
though that has softened with time. Given that I have four different
choices, I consider:

a) If it's preexisting code (especially written by someone else) I try to
maintain that style (if discernable) for consistency, subject to

b) Minimizing the need to use backslashes

I also agree about SQL. I found that something like this:

stmt = (
"""select foo from bar"""
"""  where a = 'bag'"""
"""and c = 'dog'"""
)

worked pretty well, served to both satisfy my brain's desire for semantic
indentation (you should see some of the SQL I inherited - yikes!) and
maintain a visual distinction between Python and SQL quoting. (Consistently
using triple quotes minimizes the chance of needing a stray Python
backslash inside the SQL code.) I'm now retired, so can't double check, but
I believe SQLite and MSSQL are unusual in their Pythonesque treatment of
single and double quotes being synonymous. I believe most other dialects
(Oracle, MySQL, Sybase, PostgreSQL that I checked) only recognize single
quotes as string delimiters.

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

Re: Is there some reason that recent Windows 3.6 releases don't included executable nor msi installers?

[Souvik Dutta]

And that there are no files for an installer.

Souvik flutter dev

On Sat, May 23, 2020, 4:04 PM Souvik Dutta  wrote:

> If you take a look at this page then you will find out that 3.6.10 was not
> intended to be used in windows...
> https://www.python.org/downloads/windows/
>
> Souvik flutter dev
>
> On Sat, May 23, 2020, 11:55 AM Adam Preble  wrote:
>
>> I wanted to update from 3.6.8 on Windows without necessarily moving on to
>> 3.7+ (yet), so I thought I'd try 3.6.9 or 3.6.10.
>>
>> All I see for both are source archives:
>>
>> https://www.python.org/downloads/release/python-369/
>> https://www.python.org/downloads/release/python-3610/
>>
>> So, uh, I theoretically did build a 3.6.10 .exe installer, but I don't
>> really trust I did everything right. Is there an officially sourced
>> installation?
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there some reason that recent Windows 3.6 releases don't included executable nor msi installers?

[Souvik Dutta]

If you take a look at this page then you will find out that 3.6.10 was not
intended to be used in windows...  https://www.python.org/downloads/windows/

Souvik flutter dev

On Sat, May 23, 2020, 11:55 AM Adam Preble  wrote:

> I wanted to update from 3.6.8 on Windows without necessarily moving on to
> 3.7+ (yet), so I thought I'd try 3.6.9 or 3.6.10.
>
> All I see for both are source archives:
>
> https://www.python.org/downloads/release/python-369/
> https://www.python.org/downloads/release/python-3610/
>
> So, uh, I theoretically did build a 3.6.10 .exe installer, but I don't
> really trust I did everything right. Is there an officially sourced
> installation?
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list