[issue37555] _CallList.__contains__ doesn't always respect ANY.

[Elizabeth Uselton]

Elizabeth Uselton  added the comment:

Serhiy, thanks for pointing that out. I generally agree with everything in that 
thread, and learned some new things (I had no idea count(), index() and 
remove() used needle on the left side!) However, I'm not trying to spearhead a 
rewrite of everything. I think what I'm advocating for on the two assertEqual 
order tests is that as Guido mentioned "people should fix their __eq__ 
implementation to properly return NotImplemented". _Call's __eq__ currently has 
no path to NotImplemented, and if it did, those tests would pass. Perhaps I 
should change it from the or statement to make it more clear that's what's 
effectively happening.

I'd like to talk more about what a good solution would be for the _Call __eq__ 
issue, since people (including myself!) have concerns, but I think it would be 
best to open another bug for that, and not scope creep myself. I've reverted 
all the commits having to do with that part so hopefully the issue with 
_call_matcher can get sorted separately, and then we can talk about this as 
it's own issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Namespaces: memory vs 'pollution'

[DL Neil]

On 22/07/19 5:30 AM, Roel Schroeven wrote:

DL Neil schreef op 21/07/2019 om 2:02:

How do you remember to from-import- 'everything' that is needed?
... > Upon closer inspection, I realised it didn't just fail; it 
failed badly!

Some silly, little, boy had imported the PythonEnvironment class but
failed to ALSO import PythonVersionError. So, the reported error was not
the expected exception!
...
Is there some 'easy way' to make sure that one doesn't just import the
desired class, but also remembers to import 'everything else' that might
be necessary. In this case, it'd be rather nice to:

from environment_module import Python*

NB this is a syntax error, and won't import both the PythonEnvironment
and PythonVersionError classes.

 > ...

What do you do to (respecting purism) ensure 'everything' (necessary) is
imported (and nothing more), preferably without relying upon (faulty, in
my case) human-memory or reading through volumes of code/documentation?


This is one of the advantages of using import instead of from-import.

import environment_module

...
try:
     
     # Just an example, since I don't know PythonEnvironment
     env = environment_module.PythonEnvironment()
     ...
except environment_module.PythonVersionError:
     # Handle the exception

In this case you have a pretty long module name (by the way, you could 
probably shorten it by removing _module; there's normally no need to 
repeat it in the name of a module that it's a module), making repeating 
it everywhere somewhat awkward. You can import the module using another 
name to work around that:


import environment_module as envmod

...
try:
     
     # Just an example, since I don't know PythonEnvironment
     env = envmod.PythonEnvironment()
     ...
except envmod.PythonVersionError:
     # Handle the exception



Greetings to Belgians, and thanks!

Yes, I like this (interestingly, I recall posing a question some months 
back, asking how many of us bother to check for import exceptions).



Long names: agreed, although I don't worry about it too much because 
competent editors 'pop-up' suggestions as one types. (incidentally, you 
are correct - I wouldn't really use that naming system, but inserted the 
word "module" in a bid to make the example illustrative)


The opposite is even worse (and sometimes working with statisticians I'm 
often given 'algebra' with one-letter 'variable names') - in the general 
case, I criticise non-obvious abbreviations in code-review. Yet...



Yesterday, I went 'full-circle' around the options for import statements 
(and some importlib facilities), looking at the effects on 'namespace 
pollution' and trying to find some sort of "wild-card" method. In the 
end, my conclusions were close-to, but not as well-developed as the above.



Current thoughts:

import environment_module as em

- so, even more of an abbreviation than suggested!?
- I rarely need to write a long list of import statements, so there 
won't be many.

- not normally using such abbreviations in my code, they will stand-out.
- considered using upper-case, eg "EM" - it is a form of constant after-all
- considered adding a single under(-line) suffix, eg "em_" (on the basis 
of "made you think"). No, don't make me think (too much)!
- so, perhaps a two-letter abbreviation with a single under(-line), eg 
"e_m", won't be confused with other naming conventions and yet 
stands-out. (sadly, that is "stands-out" to me, but 'everyone else' 
won't know its significance...)


The try...except construct is a brilliant idea because it does exactly 
what I asked - requires both the class (what I wanted to include) AND 
the custom-exception class (what it needs included).


If the class does not have any related error classes, then the 
try...except can simply check for 'exists?'...



It's a habit I'm about to adopt. Many thanks!
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Aioli: Non-blocking Web API framework

[Robert Wikman]

Hello,

Thought I'd announce a project I've been working on for some time.

Aioli is a Framework for building RESTful HTTP and WebSocket APIs with
asyncio. Its easy-to-use component system--built with an emphasis on
portability and composability--offers a sensible separation of application
logic, data access, and request/response layers.

Some links.

Framework Github repo:
https://github.com/aioli-framework/aioli

Documentation:
https://docs.aioli.dev

Extensions:
https://github.com/aioli-framework/aioli-rdbms -- Mysql and Postgres support
https://github.com/aioli-framework/aioli-openapi -- Generate OAS3 schemas
using Aioli Route Handlers

Fully functional (and quite comprehensive) RESTful HTTP API example:
https://github.com/aioli-framework/aioli-guestbook-example

Note that the project is still under development and lacks some features,
documentation, and tests.

Let me know if you have any questions, suggestions or such.

--
Robert Wikman
0xf6feb506ae5d3762
--
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue37647] Wrong lineno in traceback when formatting strings with % and multilines

[Bruno P. Kinoshita]

New submission from Bruno P. Kinoshita :

Hi,

Tested on Python 3.7 on Ubuntu LTS. But I believe this affects previous 
versions too, as found it from an issue posted in Jinja2 in 2013: 
https://github.com/pallets/jinja/issues/276

This code simulates the issue where the traceback has the wrong line number 
(without using any Jinja2 code):

```
class Z(object):
def __str__(self):
raise ValueError('Z error')


def raise_generator():
yield 'three values are: %s %s %s' % (
'primeiro',
Z(),  # traceback must point to this lineno 9
'terceiro'  # but points to this lineno 10 (__str__ only, __eq__ is OK)
)


print(list(raise_generator()))
```

The output:

```
Traceback (most recent call last):
  File 
"/home/kinow/Development/python/workspace/cylc-flow/cylc/flow/tests/Z.py", line 
14, in 
print(list(raise_generator()))
  File 
"/home/kinow/Development/python/workspace/cylc-flow/cylc/flow/tests/Z.py", line 
10, in raise_generator
'terceiro'  # but points to this lineno 10 (__str__ only, __eq__ is OK)
  File 
"/home/kinow/Development/python/workspace/cylc-flow/cylc/flow/tests/Z.py", line 
3, in __str__
raise ValueError('Z error')
ValueError: Z error
```

Jinja uses something similar to the class Z to raise errors when the template 
has undefined variables. The curious part is that if instead of simply 
formatting the string with "%s" % (Z()) you use "%s" % (str(Z())) or if you 
callZ().__str__(), then the traceback reports the correct line number.

Not sure if intentional, but would be nice if the traceback reported the 
correct line number, and I think other applications could end up having the 
same issue.

This is my first issue, so I apologize if I did not include enough information, 
or if there is anything missing in this ticket. Let me know if I need to update 
it with more information or formatting the code.

Would be happy to work on this if this is considered an easy-to-fix issue.

Thanks all for your work on Python,

Bruno P. Kinoshita

--
components: Interpreter Core
messages: 348277
nosy: kinow
priority: normal
severity: normal
status: open
title: Wrong lineno in traceback when formatting strings with % and multilines
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30550] Document order-preserving dictionary output in json

[Kyle Stanley]

Kyle Stanley  added the comment:

> Please keep focused on the OP's thought that the JSON docs should explicitly 
> promised that
> key/value pairs are added in the order that they are encountered. The 
> existing JSON docs imply
> this pretty strongly, but it can be made more explicit.

I agree that the behavior could be more explicitly stated in the docs, as that 
could be potentially useful information for users to be aware of. 

Apologies for derailing the topic, I became too focused on the OrderedDict vs 
Dict topic, which was only a small part of the issue. Any further discussion on 
that topic or updating the OrderedDict docs should probably be moved into it's 
own issue, if at all.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Proper shebang for python3

[Cameron Simpson]

On 21Jul2019 15:47, Peter J. Holzer  wrote:

On 2019-07-21 09:04:43 +1000, Cameron Simpson wrote:
I'm with Tim Daneliuk. The environment matters and should be honoured 
except

in extremely weird cases.


I don't think that all the scripts in /usr/bin are extremely weird
cases.


I think I'd better add some nuance to my stance.

I've no problem with all the scripts shipped from an OS vendor having 
#!/usr/bin/python (or whatever fixed path) in them. They have been 
released tested against the system python and should _expect_ to run 
against it. My position here is that the entire OS distribution 
constitutes a working (and via the #! controlled) environment.


But consider third party tools. Including personal tools, but basicly 
anything from _outside_ the local system in terms of authorship.


Particularly with a language like Python which is strongly backwards 
compatible, they should generally use "#!/usr/bin/env python" (or 
python2 or python3 as appropriate, when that matters) so that they can 
run in the environment they find themselves in.


1: You can can always execute a script via a specific interpreter 
explicitly.


2: If you want to test a script it is easier to provide an environment 
that exercises the script in a particular way than to hand patch the 
shebang lines on every run/reconfig.


3: If the script (per one of Chris' examples) requires a specific python 
such as 3.6, you can always go "#!usr/bin/env python3.6" in the script 
to express the target version and provide a executable "python3.6" name 
in you environment. I keep a personal ~/bin-local directory for just 
this kind of per-host stuff myself, and of course one can do the same 
thing in places like venvs or /usr/local/bin etc. And thus _still_ leave 
the script itself without a hardwired path.


[...]
If you require a specific outcoming, set a specific environment. It 
is under

your control. Control it.

For your specific example, "man youtube-dl" _is_ affected by the
environment. It honours the $MANPATH variable.


MANPATH is explicitely intended to control man.

But man doesn't fail if you set your PATH to something weird. It will
still invoke /usr/bin/groff even if that isn't in the PATH.
(I expected that there is also an environment variable to control that
but the manpage doesn't mention one).


Heh.

I wrote my own "man" yonks ago for various reasons. Guess what? I expect 
to type "man" and get mine most of the time, but type "man" when not me 
and get /usr/bin/man (absent weirdness). That applies interactively and 
also in scripts.


Same philosophy. Use the command name to express intent and the 
environment to choose the implementation of the intent. And so also in 
the shebang lines.


For Peter J. Holzer, if we must play the "I've been doing this 
forever" game: I've been sysadmining etc longer than your 25 years and disagree with

you.


That's fine. Unlike Tim I don't claim that anybody who disagrees with me
must be a newbie.


Aye; sorry for the snarkiness. Which is why I'm disagreeing on some 
things instead of asserting that you're wrong, because you're not 
"wrong".


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

[issue30550] Document order-preserving dictionary output in json

[Raymond Hettinger]

Change by Raymond Hettinger :


--
priority: normal -> low
versions:  -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30550] Document order-preserving dictionary output in json

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Kyle, the link you gave already discusses performance to the extent that it 
matters.  Please keep focused on the OP's thought that the JSON docs should 
explicitly promised that key/value pairs are added in the order that they are 
encountered.  The existing JSON docs imply this pretty strongly, but it can be 
made more explicit.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30550] Document order-preserving dictionary output in json

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee: docs@python -> rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37646] eval() in a list comprehension

[Raymond Hettinger]

Raymond Hettinger  added the comment:

This used to work as you expected in Python 2.

In Python 3, list comprehensions create their own inner scope just like 
generator expressions.  

Per the eval() docs, "if both dictionaries are omitted, the expression is 
executed in the environment where eval() is called." 

In your code example, the inner scope doesn't have a local variable "x", so the 
global variable "x" is retrieved.  

That said, I would have expected the inner "x" to be found as a non-local.  So 
yes, this does seem odd an it isn't really true that "the expression is 
executed in the environment where eval() is called."  Instead, it uses the 
globals() and locals() of the environment where it is called but not the nested 
scope.  Perhaps this should be clarified in the docs if it is in fact the 
intended behavior.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36018] Add a Normal Distribution class to the statistics module

[Steven D'Aprano]

Steven D'Aprano  added the comment:

I have a query about the documentation:

   The default *method* is "exclusive" and is used for data sampled
   from a population that can have more extreme values than found 
   in the samples. ...
   Setting the *method* to "inclusive" is used for describing 
   population data or for samples that include the extreme points.

In all my reading about quantile calculation methods, this is the first time 
I've come across this recommendation. Do you have a source for it or a 
justification?

Thanks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37646] eval() in a list comprehension

[Steven D'Aprano]

Steven D'Aprano  added the comment:

What leads you to believe that eval *shouldn't* work in the global scope in a 
comprehension?

If not the global scope, which scope should it be, local or nonlocal? Is the 
behaviour documented differently?

For reference, the current docs for eval are here:
https://docs.python.org/3.5/library/functions.html#eval

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36546] Add quantiles() to the statistics module

[miss-islington]

Change by miss-islington :


--
pull_requests: +14679
pull_request: https://github.com/python/cpython/pull/14899

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37646] eval() in a list comprehension

[Grzegorz Krasoń]

New submission from Grzegorz Krasoń :

eval() works in a global scope when invoked in a list comprehension.

--
components: Interpreter Core
files: demo.py
messages: 348271
nosy: Grzegorz Krasoń
priority: normal
severity: normal
status: open
title: eval() in a list comprehension
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48495/demo.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36018] Add a Normal Distribution class to the statistics module

[Raymond Hettinger]

Change by Raymond Hettinger :


--
pull_requests: +14678
pull_request: https://github.com/python/cpython/pull/14898

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32912] Raise non-silent warning for invalid escape sequences

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I think it is poor form to bombard end-users with warnings about things they 
can't fix.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32912] Raise non-silent warning for invalid escape sequences

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Here's another example from the current build of the docs using Sphinx:

(venv) ~/npython/Doc $ make html
mkdir -p build
Building NEWS from Misc/NEWS.d with blurb
PATH=./venv/bin:$PATH sphinx-build -b html -d build/doctrees -D 
latex_elements.papersize=  -W . build/html
Running Sphinx v2.1.0
/Users/raymond/npython/venv/lib/python3.8/site-packages/docutils/writers/latex2e/__init__.py:2978:
 SyntaxWarning: invalid escape sequence \l
  self.out.append('}] \leavevmode ')

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36338] urlparse of urllib returns wrong hostname

[jpic]

Change by jpic :


--
nosy: +jpic

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t

[Stefan Krah]

Stefan Krah  added the comment:

Is it available with -std=c11? It is a bit strange that we use -std=c99. I 
thought that header is C11:

https://en.cppreference.com/w/c/atomic

--
nosy: +skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t

[Glenn Johnson]

Change by Glenn Johnson :


--
nosy: +Glenn Johnson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36338] urlparse of urllib returns wrong hostname

[jpic]

Change by jpic :


--
pull_requests: +14677
pull_request: https://github.com/python/cpython/pull/14896

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17535] IDLE editor line numbers

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Ned, about window menus and Mac's single menu: tk and macOS work together to 
switch the menu to the menu of a window that becomes active.  I opened two 
editor windows and clicked 'Show Code Context' in just one of them.  The menu 
then said 'Hide Code Context'.  I clicked the other window and then Option and 
it said 'Show...'.  More experiments clicking windows and toggling CC went 
well.  Show/Hide Line Numbers is intended to work the same way.  Since Tal 
cannot now test, verification would be nice, as well as the line-up check 
described above

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17535] IDLE editor line numbers

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Tal's 2 issues above have been resolved.
1. Line numbers are initially off by default but this can be reversed on the 
Settings General tab.
2. Line numbers can be shown and hidden for a window on the Option menu.

The only bug I know of that must be fixed before merging is that font changes 
do not always get propagated to the numbers.

I recently added 1 pixel of padding to line up line numbers and text.  How is 
is on other machines?  Especially Mac, if anyone has one?  (Tal's just broke.) 
Easy test: open a new file; type multiple 2s and 7s on lines 2 and 7.  Eyeball, 
then, use paper to see if low and high horizontal lines on 2s and 7s are lined 
up properly.

--
title: IDLE: Add an option to show line numbers along the left side of the 
editor window, and have it enabled by default. -> IDLE editor line numbers

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30550] Document order-preserving dictionary output in json

[Kyle Stanley]

Kyle Stanley  added the comment:

> OrderedDict is not recommended to preserve order any more.

> Please forget about OrderedDict unless you need additional feature 
> OrderedDict provides.  It is far inefficient than regular dict.

Thanks for the clarification. Should this recommendation be briefly mentioned 
in the documentation 
(https://docs.python.org/3.9/library/collections.html#ordereddict-objects)? 

Currently, the docs reference that as of 3.7, the order-preserving behavior of 
standard dictionaries is guaranteed, but there is no mention of the significant 
differences in efficiency. Based on the current description, a user might end 
up using OrderedDictionary on the basis that they *might* have a need for 
reordering elements. 

If the difference in performance is significant enough, it would be worth 
noting in the docs so that users can take it into consideration when deciding 
which data structure to use.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How to print out html tags excluding the attributes

[Michael F. Stemper]

On 20/07/2019 20.04, sum abiut wrote:
> I want to use regular expression to print out the HTML tags excluding the
> attributes.
> 
> for example:
> 
> import re
> html = 'Hitest test'
> tags = re.findall(r'<[^>]+>', html)
> for a in tags:
> print(a)
> 
> 
> the output is :
> 
> 
> 
> 
> 
> 
> 
> 
> But I just want the tag, not the attributes

Try this:

for a in tags:
a = re.sub( " .*>", ">", a )
print(a)

(The two statements could be combined.)

-- 
Michael F. Stemper
Galatians 3:28
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue37627] Minor improvements to IDLE's "Run Customized"

[miss-islington]

miss-islington  added the comment:


New changeset 849a37a2b640af14cfb004cdbced01983b0d9d2b by Miss Islington (bot) 
in branch '3.7':
bpo-37627: Add acknowledgment (GH-14883)
https://github.com/python/cpython/commit/849a37a2b640af14cfb004cdbced01983b0d9d2b


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37627] Minor improvements to IDLE's "Run Customized"

[miss-islington]

miss-islington  added the comment:


New changeset 52ee929957871da3d2622ab16887a1a03e6e08bf by Miss Islington (bot) 
in branch '3.8':
bpo-37627: Add acknowledgment (GH-14883)
https://github.com/python/cpython/commit/52ee929957871da3d2622ab16887a1a03e6e08bf


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37627] Minor improvements to IDLE's "Run Customized"

[miss-islington]

Change by miss-islington :


--
pull_requests: +14676
pull_request: https://github.com/python/cpython/pull/14895

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37627] Minor improvements to IDLE's "Run Customized"

[miss-islington]

Change by miss-islington :


--
pull_requests: +14675
pull_request: https://github.com/python/cpython/pull/14894

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37627] Minor improvements to IDLE's "Run Customized"

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 4214f1ec3b3c73badd639229eff81eb5e57b82ec by Terry Jan Reedy in 
branch 'master':
bpo-37627: Add acknowledgment (#14883)
https://github.com/python/cpython/commit/4214f1ec3b3c73badd639229eff81eb5e57b82ec


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37627] Minor improvements to IDLE's "Run Customized"

[miss-islington]

miss-islington  added the comment:


New changeset 9325f4091b66f3a9cc85681435367671d335e3e7 by Miss Islington (bot) 
in branch '3.8':
bpo-37627: Initialize IDLE Custom Run dialog with previous entries (GH-14870)
https://github.com/python/cpython/commit/9325f4091b66f3a9cc85681435367671d335e3e7


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Counting Python threads vs C/C++ threads

[Peter J. Holzer]

On 2019-07-16 12:48:33 -0700, Dan Stromberg wrote:
> On Tue, Jul 16, 2019 at 11:13 AM Barry Scott  wrote:
> > Does top show the process using 100% CPU?
> >
> Nope.  CPU utilization and disk use are both low.
> 
> We've been going into top, and then hitting '1' to see things broken down
> by CPU core (there are 32 of them, probably counting hyperthreads as
> different cores), but the CPU use is in the teens or so.

If you had many CPU-bound Python threads, then with 32 cores each core
might show as 3 % busy (the sum of the threads can't use more then 100 %
because of the GIL and 100 / 32 = 3.125).

hp

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


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

[issue37627] Minor improvements to IDLE's "Run Customized"

[miss-islington]

Change by miss-islington :


--
pull_requests: +14674
pull_request: https://github.com/python/cpython/pull/14893

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
keywords: +patch
pull_requests: +14673
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14890

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37644] Sphinx (Travis doc build) is blocking merging

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Although the error message says line 267, the suspicious line is on 273 for the 
copies in my repository on windows.  If 267 does not work, I will revise and 
merge my overlapping PR that removes the number.  Most of the entries in 
susp-ignored.csv do not have line numbers, which seems less fragile. I don't 
think that this entry needs one either.  The prefix "This is the description of 
the" does not appear elsewhere in the file, is unlikely to, and if the sentence 
were repeated, it would likely not be an issue anyway.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37644] Sphinx (Travis doc build) is blocking merging

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +14672
pull_request: https://github.com/python/cpython/pull/14887

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37544] Test hang causes --enable-optimizations build to hang

[Gregory P. Smith]

Gregory P. Smith  added the comment:

While test hangs shouldn't happen, I recommend working around such odd 
situations you are finding on your system by supplying your own modified 
PROFILE_TASK setting at make time that avoids whatever test(s) are causing you 
problems.  The linked to issue36044 contains some suggested PROFILE_TASK 
settings.

--
title: Test failures cause --enable-optimizations build to hang -> Test hang 
causes --enable-optimizations build to hang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37644] Sphinx (Travis doc build) is blocking merging

[Ned Deily]

Change by Ned Deily :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37644] Sphinx (Travis doc build) is blocking merging

[miss-islington]

miss-islington  added the comment:


New changeset 8f501647ca1fba32204c0c1a705e06b4e43c69b1 by Miss Islington (bot) 
in branch '3.8':
Bpo-37644: update suspicious.csv for distutils/examples (GH-14885)
https://github.com/python/cpython/commit/8f501647ca1fba32204c0c1a705e06b4e43c69b1


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

4. It uses the __name__ instead of the __qualname__

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37644] Sphinx (Travis doc build) is blocking merging

[miss-islington]

Change by miss-islington :


--
pull_requests: +14671
pull_request: https://github.com/python/cpython/pull/14886

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37644] Sphinx (Travis doc build) is blocking merging

[Ned Deily]

Ned Deily  added the comment:


New changeset 22f0483d44b13140f6ea9927f0cf088c493e875a by Ned Deily in branch 
'master':
Bpo-37644: update suspicious.csv for distutils/examples (GH-14885)
https://github.com/python/cpython/commit/22f0483d44b13140f6ea9927f0cf088c493e875a


--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37644] Sphinx (Travis doc build) is blocking merging

[Ned Deily]

Change by Ned Deily :


--
keywords: +patch
pull_requests: +14670
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14885

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc

[Jeroen Demeyer]

New submission from Jeroen Demeyer :

PyEval_GetFuncName is bad API because

1. It hardcodes a limited number of function classes (which doesn't even 
include all function classes in the core interpreter) instead of supporting 
duck-typing.
2. In case of a "function" object, it relies on a borrowed reference to the 
function.
3. It is returning a C string instead of a Python string, so we cannot return a 
new reference even if we wanted to.

Since PyEval_GetFuncName and PyEval_GetFuncDesc are always used together, we 
might as well replace them by a single function with a proper API.

--
components: Interpreter Core
messages: 348255
nosy: jdemeyer, vstinner
priority: normal
severity: normal
status: open
title: Replace PyEval_GetFuncName/PyEval_GetFuncDesc
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37641] Embeddable distribution pyc filenames show build machine location

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +14669
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14884

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Namespaces: memory vs 'pollution'

[Roel Schroeven]

DL Neil schreef op 21/07/2019 om 2:02:

How do you remember to from-import- 'everything' that is needed?
... > Upon closer inspection, I realised it didn't just fail; it failed badly!
Some silly, little, boy had imported the PythonEnvironment class but
failed to ALSO import PythonVersionError. So, the reported error was not
the expected exception!
...
Is there some 'easy way' to make sure that one doesn't just import the
desired class, but also remembers to import 'everything else' that might
be necessary. In this case, it'd be rather nice to:

from environment_module import Python*

NB this is a syntax error, and won't import both the PythonEnvironment
and PythonVersionError classes.

> ...

What do you do to (respecting purism) ensure 'everything' (necessary) is
imported (and nothing more), preferably without relying upon (faulty, in
my case) human-memory or reading through volumes of code/documentation?


This is one of the advantages of using import instead of from-import.

import environment_module

...
try:

# Just an example, since I don't know PythonEnvironment
env = environment_module.PythonEnvironment()
...
except environment_module.PythonVersionError:
# Handle the exception

In this case you have a pretty long module name (by the way, you could 
probably shorten it by removing _module; there's normally no need to 
repeat it in the name of a module that it's a module), making repeating 
it everywhere somewhat awkward. You can import the module using another 
name to work around that:


import environment_module as envmod

...
try:

# Just an example, since I don't know PythonEnvironment
env = envmod.PythonEnvironment()
...
except envmod.PythonVersionError:
# Handle the exception


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

[issue37644] Sphinx (Travis doc build) is blocking merging

[Ammar Askar]

Ammar Askar  added the comment:

This particular error used to be covered here: 
https://github.com/python/cpython/blob/master/Doc/tools/susp-ignored.csv but 
looks like a line number change has broken it.

--
nosy: +ammar2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Proper shebang for python3

[Peter J. Holzer]

On 2019-07-21 10:26:17 -0500, Tim Daneliuk wrote:
> On 7/21/19 8:47 AM, Peter J. Holzer wrote:
> > That's fine. Unlike Tim I don't claim that anybody who disagrees with me
> > must be a newbie.
> 
> Peter, that's ad hominem and unfair.

No, it isn't. Please read the first paragraph of
https://en.wikipedia.org/wiki/Ad_hominem

> I never said anything close to that.

Well, let's see what you wrote:

| We don't need to bikeshed this.

Translation: This is not a matter of opinion or taste. There is one
objectively true answer.

| All we need is people who disagree with this view to spend a year in
| software packaging, operations, deployment and DevOps ... then get back
| to us...

Translation: People who disagree with your opinion obviously haven't
worked even a single year in this field because otherwise they would
have discovered the one objectively true answer.

| Grr..

I don't have to translate that :-)


> What I said is that if someone were to spend an extended period of time
> in devops and systems engineering at large scale, they'd quickly come to
> hate hardwired paths.

You are just stating the same point again: Everybody who has experience
in the field agrees with you, therefore anybody who disagrees can't have
experience.


> The truth is that there is no single answer to this problem until you
> hermetically seal an environment.

If you can hermetically seal the environment, the argument is moot. I
thought (and still think) we are talking about the case where you can't.
Therefore I took exception to your insistence that there is in fact one
single answer and that this single answer is one which I know from
bitter experience to be quite fragile.


> But short of that, the ability to decide to use something other than
> system-provided tools absolutely IS a requirement in systems of any
> scale.

I completely agree with that. I just don't think that using
#!/usr/bin/env is a good way to achieve that.

hp

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


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

[issue37644] Sphinx (Travis doc build) is blocking merging

[Terry J. Reedy]

New submission from Terry J. Reedy :

One of the required CI tests is a Travis doc build, even if a PR does not touch 
any doc file.  The following failure appears to be deterministic on master and 
3.8.  A 3.7 backport passed.  It has happened multiple times on multiple PRs 
today.  Example:
https://travis-ci.org/python/cpython/jobs/561700698
The failure is
'''
Warning, treated as error:
[distutils/examples:267] "`" found in "This is the description of the 
``foobar`` package."
'''
I have no idea why this is seen as suspicious.

I have 4 PRs blocked by this.
https://github.com/python/cpython/pull/14872
https://github.com/python/cpython/pull/14879
https://github.com/python/cpython/pull/14883
https://github.com/python/cpython/pull/14881
The last one is the 3.8 backport of a PR that passed CI maybe 12 hours ago.  
Its 3.7 backport passed and is merged.

If nothing else, can warnings not be treated as errors?

--
components: Tests
keywords: 3.8regression
messages: 348253
nosy: mdk, terry.reedy, vstinner, zach.ware
priority: critical
severity: normal
stage: needs patch
status: open
title: Sphinx (Travis doc build) is blocking merging
type: behavior
versions: Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Proper shebang for python3

[Chris Angelico]

On Mon, Jul 22, 2019 at 1:36 AM Tim Daneliuk  wrote:
>
> On 7/21/19 8:47 AM, Peter J. Holzer wrote:
> > That's fine. Unlike Tim I don't claim that anybody who disagrees with me
> > must be a newbie.
>
> Peter, that's ad hominem and unfair.  I never said anything close to that.
> What I said is that if someone were to spend an extended period of time
> in devops and systems engineering at large scale, they'd quickly come to
> hate hardwired paths.
>
> The truth is that there is no single answer to this problem until you
> hermetically seal an environment.  Docker comes close, a freestanding
> VM does this most completely.   But short of that, the ability to decide
> to use something other than system-provided tools absolutely IS a requirement
> in systems of any scale.

Your final paragraph does not justify your preceding. Yes, you need
the ability to decide to use something other than the system-provided
tool; that's why "/usr/bin/env python3" is a valid shebang. No, that
does NOT mean that people with any decent experience will "hate
hardwired paths". The hardwired path ("#!/usr/bin/python3") has its
own value. Thanks to an absolute path in its shebang, I can run "sudo
iotop" regardless of whether I have a venv active. I cannot run "sudo
python3 `which iotop`" reliably, because that command uses the
environment to look things up.

You're absolutely right that there's no single answer to the problem.
That's why script authors have the option to use any path they like,
including /usr/bin/env.

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

[issue37627] Minor improvements to IDLE's "Run Customized"

[miss-islington]

miss-islington  added the comment:


New changeset d9086f2324264e93155dd81f4484975215e38f00 by Miss Islington (bot) 
in branch '3.7':
bpo-37627: Initialize IDLE Custom Run dialog with previous entries (GH-14870)
https://github.com/python/cpython/commit/d9086f2324264e93155dd81f4484975215e38f00


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1346874] httplib simply ignores CONTINUE

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy:  -terry.reedy
versions:  -Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37627] Minor improvements to IDLE's "Run Customized"

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +14668
pull_request: https://github.com/python/cpython/pull/14883

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37627] Minor improvements to IDLE's "Run Customized"

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 35b87e6001bd991f625abe305951c77ddeb9a9c5 by Terry Jan Reedy 
(Ngalim Siregar) in branch 'master':
bpo-37627: Initialize IDLE Custom Run dialog with previous entries (#14870)
https://github.com/python/cpython/commit/35b87e6001bd991f625abe305951c77ddeb9a9c5


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37627] Minor improvements to IDLE's "Run Customized"

[miss-islington]

Change by miss-islington :


--
pull_requests: +14666
pull_request: https://github.com/python/cpython/pull/14881

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1346874] httplib simply ignores CONTINUE

[Tim B]

Tim B  added the comment:

I've created a PR to potentially implement this in 3.9. Please take a look and 
review/test, if this issue is still relevant to you.

--
nosy: +tbartlett0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37627] Minor improvements to IDLE's "Run Customized"

[miss-islington]

Change by miss-islington :


--
pull_requests: +14667
pull_request: https://github.com/python/cpython/pull/14882

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Proper shebang for python3

[Tim Daneliuk]

On 7/21/19 8:47 AM, Peter J. Holzer wrote:
> That's fine. Unlike Tim I don't claim that anybody who disagrees with me
> must be a newbie.

Peter, that's ad hominem and unfair.  I never said anything close to that.
What I said is that if someone were to spend an extended period of time
in devops and systems engineering at large scale, they'd quickly come to
hate hardwired paths.

The truth is that there is no single answer to this problem until you
hermetically seal an environment.  Docker comes close, a freestanding
VM does this most completely.   But short of that, the ability to decide
to use something other than system-provided tools absolutely IS a requirement
in systems of any scale.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue1346874] httplib simply ignores CONTINUE

[Tim B]

Change by Tim B :


--
versions: +Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1346874] httplib simply ignores CONTINUE

[Tim B]

Change by Tim B :


--
pull_requests: +14665
pull_request: https://github.com/python/cpython/pull/14880

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37605] CI should not depend on gmane response

[Terry J. Reedy]

Terry J. Reedy  added the comment:

gmane was down awhile yesterday, so another merge (temporarily) blocked because 
of this.  If either of you knows how to fix this, please do so.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37643] Except clause

[Eric V. Smith]

Eric V. Smith  added the comment:

Yes, this should be discussed on python-ideas first, so I'm closing it here.

But to be honest with you, there's really no chance this would get accepted. 
It's just too easy to do it with existing list comprehension syntax, which is 
much more general purpose.

>>> [v for v in [1, 2, 3, 4, 5] if not v in [2]]
[1, 3, 4, 5]

--
nosy: +eric.smith
resolution:  -> postponed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37544] Test failures cause --enable-optimizations build to hang

[Ned Deily]

Change by Ned Deily :


--
title: Multiple test failures during build -> Test failures cause 
--enable-optimizations build to hang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33467] Python 3.7: profile-opt build errors because a test seems to hang

[Ned Deily]

Ned Deily  added the comment:

Thanks for your report.  I'm sorry we haven't replied to it before now.  
Similar behavior has been more recently reported in Issue37544 and there is 
discussion going on there.  So I am going to close your issue as a duplicate of 
it; feel free to join in the discussion there.

--
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Multiple test failures during build

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37544] Multiple test failures during build

[Ned Deily]

Ned Deily  added the comment:

Thanks for the additional info.  I see two issues here.  One, you are building 
with OpenSSL 1.1.1, the initial release back in 2018-09.  There have been a few 
releases since then (currently at 1.1.1c) which do fix problems.  You should 
try to upgrade it.

Second, and more importantly, is that "make run_profile_task" hangs because a 
test hangs up and the tests are being run sequentially (i.e. without regrtest 
-j options meaning tests all run in one process sequentially).  These days 
nearly all our testing using -j because of the possibility of individual tests 
failures and residual effects between tests. And note that "make test", which 
runs in parallel, did complete. I see there is some discussion going on 
Issue36044 about changing the set of tests run_profile_task uses which would 
likely mitigate problems like this.  I'm CCing gps here for his views.

It also appears Issue33467 is a similar report.  I'm going to close it as a 
duplicate of this one.

--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19113] duplicate test names in Lib/ctypes/test/test_functions.py

[hai shi]

hai shi  added the comment:

en, in python 3.8.0a3, I got those other error info:

$ /home/shihai/workspace/cpython/python test_functions.py

ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "/home/shihai/workspace/cpython/Lib/hashlib.py", line 244, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/home/shihai/workspace/cpython/Lib/hashlib.py", line 113, in 
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5

but in master branch, the test case is ok.

--
nosy: +shihai1991

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36564] Infinite loop with short maximum line lengths in EmailPolicy

[Ned Deily]

Change by Ned Deily :


--
keywords: +security_issue
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37642] timezone allows no offset from range (23:59, 24:00)

[Ngalim Siregar]

Change by Ngalim Siregar :


--
keywords: +patch
pull_requests: +14664
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14878

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36564] Infinite loop with short maximum line lengths in EmailPolicy

[Ned Deily]

Ned Deily  added the comment:


New changeset 79a47e2b9cff6c9facdbc022a752177ab89dc533 by Ned Deily (Miss 
Islington (bot)) in branch '3.6':
Fix infinite loop in email folding logic (GH-12732) (GH-14799)
https://github.com/python/cpython/commit/79a47e2b9cff6c9facdbc022a752177ab89dc533


--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Namespaces: memory vs 'pollution'

[Peter J. Holzer]

On 2019-07-21 12:02:27 +1200, DL Neil wrote:
> What do you do to (respecting purism) ensure 'everything' (necessary) is
> imported (and nothing more), preferably without relying upon (faulty, in my
> case) human-memory or reading through volumes of code/documentation?

I write tests (not as consistently as I would like).

I don't think there is much more you can do. The problem is that Python
doesn't have variable declarations, so there is no reliable way to
discover an undefined symbol except by executing the line where it is
used.

An IDE might help. Even though the problem is in general not solvable,
most uses of symbols fall into a few common categories which can be
discovered by static analysis. So an IDE (or even a syntax-highlighting
editor) could flag all symbols where it can't find the definition.

hp

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


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

Re: Proper shebang for python3

[Peter J. Holzer]

On 2019-07-21 09:04:43 +1000, Cameron Simpson wrote:
> On 21Jul2019 08:14, Chris Angelico  wrote:
> > On Sun, Jul 21, 2019 at 5:26 AM Tim Daneliuk  wrote:
> > > So, no, do NOT encode the hard location - ever.  Always use env to
> > > discover the one that the user has specified.  The only exception
> > > is /bin/sh which - for a variety of reasons - can reliably counted
> > > upon.
> > 
> > A quick grep through my $PATH shows that there are a number of
> > executable Python scripts there, including add-apt-repository,
> > calibre, some lilypond stuff, trash-can management, samba-tool, iotop,
> > and youtube-dl. If I have a venv active with, say, Python 3.9, then
> > `/usr/bin/env python` is going to point to Python 3.9. What are the
> > odds that all those scripts will work with Python 3.9 with no
> > libraries installed? Why should typing "youtube-dl B7xai5u_tnk" be
> > affected by a virtual environment, when typing "man youtube-dl"
> > wouldn't be?? Using env for everything is a terrible idea and one that
> > will basically make virtual environments useless.
> 
> I'm with Tim Daneliuk. The environment matters and should be honoured except
> in extremely weird cases.

I don't think that all the scripts in /usr/bin are extremely weird
cases.


> If you require a specific outcoming, set a specific environment. It is under
> your control. Control it.
> 
> For your specific example, "man youtube-dl" _is_ affected by the
> environment. It honours the $MANPATH variable.

MANPATH is explicitely intended to control man.

But man doesn't fail if you set your PATH to something weird. It will
still invoke /usr/bin/groff even if that isn't in the PATH.
(I expected that there is also an environment variable to control that
but the manpage doesn't mention one).


> For Peter J. Holzer, if we must play the "I've been doing this forever"
> game: I've been sysadmining etc longer than your 25 years and disagree with
> you.

That's fine. Unlike Tim I don't claim that anybody who disagrees with me
must be a newbie.

hp

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


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

[issue37642] timezone allows no offset from range (23:59, 24:00)

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Proper shebang for python3

[Peter J. Holzer]

On 2019-07-20 15:26:46 -0500, Tim Daneliuk wrote:
> On 7/20/19 2:56 PM, Peter J. Holzer wrote:
> > On 2019-07-20 14:11:44 -0500, Tim Daneliuk wrote:
> >> So, no, do NOT encode the hard location - ever.  Always use env to
> >> discover the one that the user has specified.  The only exception is
> >> /bin/sh which - for a variety of reasons - can reliably counted upon.
> >>
> >> We don't need to bikeshed this.  All we need is people who disagree
> >> with this view to spend a year in software packaging, operations,
> >> deployment and DevOps ... then get back to us...
> >
> > After 25 years in software packaging, operations, deployment and DevOps
> > I disagree: A program should not behave differently because of a
> > different path, #!/usr/bin/env is a total no-no.
> >
> > There is a nice way to achieve this: Just use the interpreter of the
> > virtual environment in the shebang.
> > (That requires rewriting the shebang during installation, but that's a
> > minor inconvenience)
> 
> 
> And what happens with programs that have no virtenv equivalent?
> perl, go, ruby, awk, sed, grep, etc. have no simple way to
> get installed virtual short of insisting the everything live in a
> docker container or VM?

Perl is an excellent example: When you install a Perl script which has
been packaged with one of the usual tools (e.g., Makemaker or
Module::Build), the shebang is set to the interpreter used for
installation. The user of the script doesn't have to know what
environment to use. (Perl also has perlbrew which is similar to virtual
environments, but I haven't used that much).

Go is a compiled language: The executables are binaries (no shebang) and
even statically linked. Again, the user doesn't have to care about a
language environment.

awk, grep, sed, etc. are often used in shell scripts, and they were
probably the reason why I first developed a "a program's behaviour must
not depend on the environment /except as documented/" policy: Back then
in the 1990s one usually wanted to have GNU awk, sed, grep etc. in
addition to the system utilities. Having scripts randomly fail or
(worse) produce wrong results depending on the order of /usr/bin and
/usr/local/bin in the user's PATH and the exact contents of
/usr/local/bin wasn't fun (oh, and don't forget cron).


> The fact is that most large compute environments are slow to upgrade
> the OS.  That means core tools also lag considerably behind as well.
> Being able to install newer versions along side the OS' own and then
> use them by default is manifestly necessary.

I agree. But (for me at least) it is important to do that robustly, and
#!/usr/bin/env is not robust. 

> That's why users have the ability to modify $PATH to suit their own
> needs.  All /usr/bin/env does is to tell the interpreter, "honor the
> intent of the spawning shell".

You probably just phrased that badly, but as written this is completely
wrong: /usr/bin/env doesn't tell the interpreter anything. It *chooses*
the interpreter to invoke.


> If you want really big fun, try going into an older CentOS or RedHat 
> instances and, say,
> upgrading system python to python3.

Don't do that. Install python3 somewhere else, e.g. into /usr/local.

> It's super fun.  Yes, in that case, you COULD use a venv.  But there
> are tons of other tools for which this is not an option - gcc,
> autoconf, perl, go awk, sed, bash, ad infinitum, ad nauseum are
> invariably backleveled on production OS instances.  My way fixes that
> problem.

Your way only fixes your problem only if environments where your script
may be called. You may know that /usr/local/bin/foo is a python script
that requires /usr/local/python3.8/bin/python to be in the path before
any other python interpreter and you may rememmber that in every
instance where that script is called directly or indirectly. But do your
colleagues? Especially if they aren't programmers?

And what happens if /usr/local/bin/bar requires
/usr/local/python3.4/bin/python? Do you explicitely set the PATH before
invoking each script?

By putting #!/usr/local/python3.8/bin/python at the top of
/usr/local/bin/foo and #!/usr/local/python3.4/bin/python at the top of
/usr/local/bin/bar I can just invoke both scripts. Even better, my users
can invoke both scripts and they don't even have to know they are
written in Python.


> You may have 25 years at this but I have 40 - does that make me nearly twice
> as right?  Arguments from authority are silly.

No, but it invalidates your notion that anybody with a bit of experience
would obviously use #!/usr/bin/env. I do have a bit more than one year
of experience and I think #!/usr/bin/env is a terrible idea. (I use it
for throwaway scripts which need a venv, but not for anything in
production.)

hp

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

[issue37643] Except clause

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I guess you are popping 2 from the list and using except for the same. New 
syntax and semantics needs to be discussed in python-ideas mailing list. Though 
this reads like English except is used for exception based semantics. I would 
propose closing this and reopen if it's agreed by core devs in the mailing list.

--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

docutils release 0.15

[engelbert gruber]

Note
   Docutils 0.15.x is compatible with Python versions 2.6, 2.7 and 3.3 to
3.5

* reStructuredText:

  - Allow embedded colons in field list field names (before, tokens like
``:this:example:`` were considered ordinary text).

  - Fixed a bug with the "trim" options of the "unicode" directive.

* languages: Added Korean (ko) mappings and latin.

* Several fixes to keep mor information on source in parsed elements,
  isolate documents roles from other documents parsed, smartquotes,
  table gets width and latex table multicolumn cells, ...

all the best
 engelbert
--
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue37642] timezone allows no offset from range (23:59, 24:00)

[Paul Ganssle]

Paul Ganssle  added the comment:

I agree that the C and Python behavior should be the same, and both of them 
should allow all offsets less than 24 hours. I'm actually quite surprised we 
don't have a test for this in `datetimetester.py`.

--
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37636] Deprecate slicing and ordering operations on sys.version

[Paul Ganssle]

Paul Ganssle  added the comment:

> So is the proposed change, in a way. At some point, there will be a 4.0 
> release, which may or may not break the code in question.

I don't think it's a foregone conclusion that there will be a 4.0 release. It 
could be that we decide that a 4.0 release would be reserved for a very 
specific kind of major compatibility breakage and that we were never going to 
do that kind of breakage again.

In any case, I think one part of what Serhiy was trying to say is that we can't 
just avoid this problem by releasing 4.0 instead of 3.10, because switching to 
4.0 brings its own (not inconsiderable) host of problems. Presumably the 
symlink would be `python4` instead of `python3`, so a bunch of shebangs, 
documentation and guides would need to be updated.

Basically, unless something changes, a bunch of stuff is going to break in the 
release after 3.9 no matter what we do. It's probably a good idea to try to 
mitigate the problems of *both* versioning approaches, to give us maximum 
freedom in our choice of versioning scheme int he future.

--
nosy: +p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37636] Deprecate slicing and ordering operations on sys.version

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I think it is better to left this on third-party linters.

* It is easy to catch patterns like `sys.version_info[0] == 3` or 
`sys.version[:3]` in the linter than in the Python compiler or interpreter. 
Linters are designed for this.

* Not always slicing sys.version is an error. For example, 
`sys.version[:sys.version.index(' ')]` is a valid code. Linters have options 
which allow to ignore some kind of warnings or warnings at the particular line.

* Users that ignore linters usually do not check the version. They wrote their 
scripts for the default system Python and update them when they become broken 
after system upgrade.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30550] Document order-preserving dictionary output in json

[Eric O. LEBIGOT]

Eric O. LEBIGOT  added the comment:

The essence of the original post is simply to document any order-preserving 
properties of the Python to JSON and JSON to Python transformation for 
mappings. This way users can rely on it. This is for instance useful if a 
program modifies JSON created by a user and wants to preserve the user ordering.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37643] Except clause

[Артур Григорьев]

New submission from Артур Григорьев :

Is is possible to add to Python the following syntax (keyword 'except'):
[1, 2, 3, 4, 5] except [2]
>>> [1, 3, 4, 5]

--
messages: 348238
nosy: Артур Григорьев
priority: normal
severity: normal
status: open
title: Except clause
type: enhancement
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Proper shebang for python3

[eryk sun]

On 7/20/19, Michael Speer  wrote:
>
> You may want to use `#!/usr/bin/env python3` instead.

This is partially supported in Windows, but only if .py files are
associated with the py.exe launcher and the shebang runs "python"
instead of "python3".

py.exe supports four builtin virtual commands: "/usr/bin/env python",
"/usr/bin/python", "/usr/local/bin/python", and "python". The "python"
command can be qualified with a version specification of the form
"X[.Y][-32|-64]", such as "python3". The "/usr/bin/env python" virtual
command searches PATH, but only if the command matches "python"
exactly. If there's a version specified, or if it's not an "env"
virtual command, the launcher looks for a registered Python
installation instead of searching PATH.

For all other commands, the launcher skips a virtual Unix prefix (i.e.
"/usr/bin/env", "/usr/bin", and "/usr/local/bin"), if present, and
searches PATH. For example, given "/usr/bin/pypy", it searches PATH
for "pypy" plus the file extensions in PATHEXT (i.e. .COM, .EXE, etc).
If the command isn't found in PATH, it checks in the "[commands]"
section of "%LocalAppData%\py.ini". For example, py.ini could define
"pypy=C:\PyPy71\pypy.exe".

A virtual environment should have a "python" executable, so shebangs
that use "/usr/bin/env python" will prefer an active virtual
environment. But a lot of scripts use "python3" instead of "python".
This is a stumbling block in Windows since we don't install versioned
"pythonX[.Y].exe" binaries. Thus the "env" virtual command is special
cased to find a qualified Python version in the list of registered
Python installations instead of searching PATH. (The new store app
distribution does install versioned app links, but, even in this case,
virtual environments lack versioned binaries in the "Scripts"
directory.)

That said, some developers manually create versioned binaries as
symlinks, hardlinks, or copies. Also, maybe a future version of the
full (non-app) Python installation will do the same. Thus I think the
launcher should search PATH for all "/usr/bin/env python*" shebangs,
but without the binary-type specification (i.e. "-32" or "-64") if
present. In this case, instead of a regular search based on WINAPI
SearchPath, we'll need a custom search that tokenizes and walks PATH
and checks the binary type via GetBinaryTypeW. If no matching version
is found in PATH, the "env" search should fall back on the list of
registered versions.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue37642] timezone allows no offset from range (23:59, 24:00)

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +belopolsky, p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37642] timezone allows no offset from range (23:59, 24:00)

[Jörn Heissler]

New submission from Jörn Heissler :

https://bugs.python.org/issue5288 changed datetime.timezone to accept 
sub-minute offsets.

The C implementation allows offsets from range (23:59, 24:00) while the python 
implementation does not:

# C
>>> timezone(timedelta(seconds=86399))
datetime.timezone(datetime.timedelta(seconds=86399))

# Python
>>> timezone(timedelta(seconds=86399))
Traceback (most recent call last):
  File "", line 1, in 
  File "cpython/Lib/datetime.py", line 2194, in __new__
raise ValueError("offset must be a timedelta "
ValueError: offset must be a timedelta strictly between -timedelta(hours=24) 
and timedelta(hours=24).

This is because _maxoffset is defined as timedelta(hours=23, minutes=59)

Second issue: The (undocumented) "min" and "max" attributes (both C and python) 
show 23:59
even though the C implementation can get closer to 24:00.
Should this be changed to timezone(timedelta(seconds=86399, 
microseconds=99))?


(Same applies to the minimums)

--
components: Library (Lib)
messages: 348237
nosy: joernheissler
priority: normal
severity: normal
status: open
title: timezone allows no offset from range (23:59, 24:00)
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37636] Deprecate slicing and ordering operations on sys.version

[Stefan Behnel]

Stefan Behnel  added the comment:

> Changing the major version number itself is a breaking change

So is the proposed change, in a way. At some point, there will be a 4.0 
release, which may or may not break the code in question. So, testing for 
"version_info[0] == 3" is already wrong, because that code almost certainly 
wants to know if it runs in Py2 and not if it runs in Py3. It's better fixed 
soon, before we get too close to Py4, and I think a deprecation notice could be 
helpful for that. Preferably for as many of the non-future-proof spellings as 
possible.

--
nosy: +scoder

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37641] Embeddable distribution pyc filenames show build machine location

[Bill Collins]

New submission from Bill Collins :

pyc files within the embeddable zip are compiled with their filename as the 
temporary directory in which they are compiled. Thus, stack traces will appear 
as (e.g.) D:\obj\windows-release\37win32_Release\msi_python\zip_win32\image.py, 
which is a little surprising and not obvious that it's actually from 
email/mime/image.py.

We currently work around this by updating the pyc files before shipping to be 
relative paths to Lib/; however, fixing this upstream would appear to be as 
simple as passing through the dest from _write_to_zip to _py_temp_compile 
(https://github.com/python/cpython/blob/21a92f8cda525d25a165b773fbe1bfffd303a000/PC/layout/main.py#L302)
 to be passed into _compile_one_py

--
components: Build, Installation, Windows
messages: 348235
nosy: Bill Collins, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Embeddable distribution pyc filenames show build machine location
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37549] os.dup() fails for standard streams on Windows 7

[Sebastian Bank]

Change by Sebastian Bank :


--
nosy: +xflr6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28869] __module__ attribute is not set correctly for a class created by direct metaclass call

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

FWIW I like Serhiy's approach more. I have never seen a single metaclass 
overriding type.__call__, while overriding type.__new__ is a common practice.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37640] telnetlib crash in Python3 while receiving un-printable characters from server

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +14663
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14877

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37640] telnetlib crash in Python3 while receiving un-printable characters from server

[hoang nguyen]

New submission from hoang nguyen :

```
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.7/site-packages/Pwn/Pwn.py", line 209, in io
self.con.interact()
  File 
"/usr/local/Cellar/python/3.7.3/Frameworks/Python.framework/Versions/3.7/lib/python3.7/telnetlib.py",
 line 553, in interact
sys.stdout.write(text.decode('ascii'))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 41: 
ordinal not in range(128)
```
crash detail

set up a netcat server:
```
cat /dev/urandom | nc -l 127.0.0.1 
```

test.py
```
import telnetlib

tn = telnetlib.Telnet('127.0.0.1', )
tn.interact()
```

--
components: Library (Lib)
files: test.py
messages: 348233
nosy: hoang nguyen
priority: normal
severity: normal
status: open
title: telnetlib crash in Python3 while receiving un-printable characters from 
server
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file48494/test.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Proper shebang for python3

[Brian Oney via Python-list]

On July 21, 2019 10:04:47 AM GMT+02:00, Manfred Lotz  wrote:
>On Sun, 21 Jul 2019 10:21:55 +1000
>Cameron Simpson  wrote:
>
>> On 21Jul2019 09:31, Chris Angelico  wrote:
>> >On Sun, Jul 21, 2019 at 9:15 AM Cameron Simpson 
>> >wrote: So you mean that a tool that depends on running on a
>> >consistent environment, it should use a shebang of
>> >"/usr/bin/python3.6" instead of "/usr/bin/env python3"?  
>> 
>> Jeez. No. That is the _opposite_ of what I'm saying.
>> 
>> >Because, wow, that would be exactly what is
>> >already happening on my system. Why use /usr/bin/env and then wrap
>> >something around it to force the environment, when you could just
>set
>> >a correct shebang so it properly defines its execution environment? 
>
>> 
>> Because the shebang is hardwired and inflexible.
>> 
>> Because it means hand patching (even scripted) a bazillion scripts to
>
>> that they know their physical install.
>> 
>> Because it presumes detailed hardwired knowledge of the target system
>> in a script which should work anywhere.
>> 
>> Instead a tiny _common_ shell script resembling this:
>> 
>>   #!/bin/sh
>>   # Run command in the official environment.
>>   exec env - PATH=/path/to/3.6venv/bin:/usr/sbin:/bin exec ${1+"$@"}
>> 
>> arranges things. The "env -" is aimed at "clean" daemon or install 
>> environments.  You can do subtler or less intrusive things in other 
>> settings.
>> 
>
>I took a look and found that Fedora 30 and Debian Jessie both use
>hard-wired paths for python in the rpm resp. deb packages.
>
>I'm being new to Python and I am not acquainted in any way with
>virtualenv resp. venv so cannot currently judge its pro and cons.
>
>So I will stick to:
>   #!/usr/bin/env python3 
>
>as shebang for my scripts.

I think that's a good decision. Most of the conversation applies to sysadmins 
concerned with answering your question in absolute terms. When you start 
writing scripts which are restricted to a specific environment and are intended 
to be distributed, you may revisit this thread.

Be blissful until then :). Chris et al have "fixed" things for you.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30550] Document order-preserving dictionary output in json

[Inada Naoki]

Inada Naoki  added the comment:

OrderedDict is not recommended to preserve order any more.

Note that mention about `object_pairs_hook=OrderedDict` is removed 
intentionally.
https://github.com/python/cpython/pull/5001

Please forget about OrderedDict unless you need additional feature OrderedDict 
provides.  It is far inefficient than regular dict.

--
nosy: +inada.naoki

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Proper shebang for python3

[Manfred Lotz]

On Sun, 21 Jul 2019 10:21:55 +1000
Cameron Simpson  wrote:

> On 21Jul2019 09:31, Chris Angelico  wrote:
> >On Sun, Jul 21, 2019 at 9:15 AM Cameron Simpson 
> >wrote: So you mean that a tool that depends on running on a
> >consistent environment, it should use a shebang of
> >"/usr/bin/python3.6" instead of "/usr/bin/env python3"?  
> 
> Jeez. No. That is the _opposite_ of what I'm saying.
> 
> >Because, wow, that would be exactly what is
> >already happening on my system. Why use /usr/bin/env and then wrap
> >something around it to force the environment, when you could just set
> >a correct shebang so it properly defines its execution environment?  
> 
> Because the shebang is hardwired and inflexible.
> 
> Because it means hand patching (even scripted) a bazillion scripts to 
> that they know their physical install.
> 
> Because it presumes detailed hardwired knowledge of the target system
> in a script which should work anywhere.
> 
> Instead a tiny _common_ shell script resembling this:
> 
>   #!/bin/sh
>   # Run command in the official environment.
>   exec env - PATH=/path/to/3.6venv/bin:/usr/sbin:/bin exec ${1+"$@"}
> 
> arranges things. The "env -" is aimed at "clean" daemon or install 
> environments.  You can do subtler or less intrusive things in other 
> settings.
> 

I took a look and found that Fedora 30 and Debian Jessie both use
hard-wired paths for python in the rpm resp. deb packages.

I'm being new to Python and I am not acquainted in any way with
virtualenv resp. venv so cannot currently judge its pro and cons.

So I will stick to:
   #!/usr/bin/env python3 

as shebang for my scripts.


-- 
Manfred


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

[issue37380] subprocess.Popen._cleanup() "The handle is invalid" error when some old process is gone

[Emanuel Zephir]

Emanuel Zephir  added the comment:

I believe this to be a bug in the standard library instead of solely being the 
result of an application error.

When a Popen instance is finalized by the garbage collector, the internal 
handle is also finalized and closed despite the instance being put on the 
active list. This results in _cleanup throwing because the handle can no longer 
be used.

I've attached a small reproduction.

--
nosy: +emanuel
Added file: https://bugs.python.org/file48493/invalid_handle.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Proper shebang for python3

[Barry Scott]

> On 21 Jul 2019, at 08:29, Christian Gollwitzer  wrote:
> 
> Am 21.07.19 um 07:31 schrieb Tim Daneliuk:
>> On 7/20/19 6:04 PM, Chris Angelico wrote:
>>> Are you aware of every systemwide command that happens to be
>>> implemented in Python, such that you won't execute any of them while
>>> you have the venv active?
>> No, but this has never been a problem because the newer versions of
>> python tend to be pretty good - within a major release tree - of being
>> backward compatible.  Certainly, if I were running, say, RedHat 4 with
>> a very new version of python in my path first, this could theoretically
>> be an issue.  I've just not run into it.
> 
> It's not about the core language, but these system tools depend on packages, 
> sometimes specialist packages, which might not be available in your venv.

Well said.

The fedora packaging system replaces all shebang lines with the full path to 
either python2 or python3 on the system
to make sure that scripts installed in the system run as intended and do not 
break because of the users PATH.

How you think about the shebang lines depends on where the scripts will be used.

If its as an installed system component the exact path is usually the right 
thing to do.

If it you personal scripts then you may well find /usr/bin/env python3 makes 
you life
simpler.

For code I'm testing I usual do not depend no shebang lines at all. Often I'm 
testing
on many python versions. And end up with something like this to test on all 
interesting python
versions.

for PTYHON in python3.6 python3.7 python3.8
do
$PYTHON my_script.py
done

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

[issue36324] Inverse cumulative normal distribution function

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset c613c3319ed9bdc8cd74c730ad946169c0776c8a by Raymond Hettinger 
(Miss Islington (bot)) in branch '3.8':
bpo-36324: Make internal attributes for statistics.NormalDist() private. 
(GH-14871) (GH-14875)
https://github.com/python/cpython/commit/c613c3319ed9bdc8cd74c730ad946169c0776c8a


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34224] python 3.7 inside venv tries to write back to read-only installation directory (Grammar3.7.0.final.0.pickle)

[Andreas Jung]

Andreas Jung  added the comment:

This issue is still true for 3.8.0b1, Ubuntu 19.04, umask is 0077, Python 3.8 
is installed using "sudo make install".

!bin/python
bin/python setup.py develop
running develop
running egg_info
writing fs.webdavfs.egg-info/PKG-INFO
writing dependency_links to fs.webdavfs.egg-info/dependency_links.txt
writing entry points to fs.webdavfs.egg-info/entry_points.txt
writing requirements to fs.webdavfs.egg-info/requires.txt
writing top-level names to fs.webdavfs.egg-info/top_level.txt
error: [Errno 13] Permission denied: 
'/opt/python-3.8.0b1/lib/python3.8/lib2to3/Grammar3.8.0.beta.1.pickle'


So "python3 -m venv" should setup a virtualenv properly without the need 
writing anything to the Python installation directory. Or it is up to "make 
install" to generate the related files properly during installation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36324] Inverse cumulative normal distribution function

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 02c91f59b6f6e720a9e89635e00c55bcf7f932a8 by Raymond Hettinger in 
branch 'master':
bpo-36324: Make internal attributes for statistics.NormalDist() private. 
(GH-14871)
https://github.com/python/cpython/commit/02c91f59b6f6e720a9e89635e00c55bcf7f932a8


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36324] Inverse cumulative normal distribution function

[miss-islington]

Change by miss-islington :


--
pull_requests: +14662
pull_request: https://github.com/python/cpython/pull/14875

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Proper shebang for python3

[Christian Gollwitzer]

Am 21.07.19 um 07:31 schrieb Tim Daneliuk:

On 7/20/19 6:04 PM, Chris Angelico wrote:

Are you aware of every systemwide command that happens to be
implemented in Python, such that you won't execute any of them while
you have the venv active?


No, but this has never been a problem because the newer versions of
python tend to be pretty good - within a major release tree - of being
backward compatible.  Certainly, if I were running, say, RedHat 4 with
a very new version of python in my path first, this could theoretically
be an issue.  I've just not run into it.



It's not about the core language, but these system tools depend on 
packages, sometimes specialist packages, which might not be available in 
your venv.


Christian

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

[issue30550] Document order-preserving dictionary output in json

[Kyle Stanley]

Kyle Stanley  added the comment:

>Thus, if a user gives an OrderedDict (or a dict with a known order, in Python 
>3.7+), it is useful that >he know that the order of its elements will not be 
>changed upon transformation into JSON.

I would agree that it could be helpful to document that if a user passes an 
OrderedDict, the order of the elements will not changed, I was just pointing 
out that a default dictionary implementation would not normally retain the 
order. 

However, after looking through the 3.7 changes and reading the discussions, it 
looks like dictionaries retaining insertion order was decided to be made an 
official part of the language. If the order matters though, it would make sense 
to recommend users to use OrderedDict. The order in the default dictionary 
implementation can end up becoming sorted if pprint is used.

Discussions: 
https://mail.python.org/pipermail/python-dev/2017-December/151283.html and 
https://mail.python.org/pipermail/python-dev/2017-December/151376.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com