[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +4348

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 9165f77d5f93a2c12aa0e90853e3ae7212800d3c by Serhiy Storchaka in 
branch 'master':
bpo-32012: Disallow trailing comma after genexpr without parenthesis. (#4382)
https://github.com/python/cpython/commit/9165f77d5f93a2c12aa0e90853e3ae7212800d3c


--

___
Python tracker 

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

[issue32028] Syntactically wrong suggestions by the new custom print statement error message

[Sanyam Khurana]

Sanyam Khurana  added the comment:

Sure, let me have a look at it and work on fix.

--

___
Python tracker 

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

[issue32028] Syntactically wrong suggestions by the new custom print statement error message

[Nick Coghlan]

Nick Coghlan  added the comment:

Given the symptoms (stripping 4 spaces + "pr" from the start of the line, 
leaving "int " behind), it looks like we're not stripping the leading 
whitespace when determining the text to include in the suggested print() call.

To reproduce this at the REPL, you can use an if statement (first example uses 
a 4 space indent, the second uses an 8 space indent):

```
>>> if 1:
... print 123
  File "", line 2
print 123
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int 
123)?
>>> if 1:
... print 123
  File "", line 2
print 123
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(print 
123)?

```

--
stage:  -> test needed
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

[issue32026] Memory leaks in Python on Windows

[Nick Coghlan]

Nick Coghlan  added the comment:

I think it's reasonable to keep this open if the problems can be reproduced 
with the current 3.7 dev branch - while we've refactored a lot of things, we 
haven't specifically gone memory leak hunting for the embedded case, and I'm 
pretty sure there are still some items where we delay cleaning them up until 
the next Py_Initialize call.

The relevant embedding test case is the one at 
https://github.com/python/cpython/blob/master/Programs/_testembed.c#L41, but 
I'm not sure we regularly run that in a way that would reliably detect memory 
leaks (it runs in a subprocess, rather than the main process, so the refleak 
hunting runs may not be handling it properly).

--
nosy: +haypo

___
Python tracker 

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

Re: inspecting a callable for the arguments it accepts

[Chris Angelico]

On Wed, Nov 15, 2017 at 4:34 PM, Gregory Ewing
 wrote:
> Chris Angelico wrote:
>
> wants_one_arg.__code__.co_argcount
>>
>>
>> 1
>>
> wants_one_arg.__code__.co_varnames
>>
>>
>> ('x',)
>
>
> That will give you some idea, but it's not foolproof -- e.g.
> if the function has * or ** arguments, it's impossible to tell
> in general how many arguments it accepts without studying the
> code (and maybe not even then -- halting problem, etc.)
>
> Some of the co_flags seem to indicate presence of * and **:
>
> 0x04 - has *args
> 0x08 - has **kwds
>
> In Py3 there is also co_kwonlyargcount.

Yep. Browsing __code__'s attributes was the stepping-stone to the
actual way of doing it: the inspect module. But I figured it's better
to look at those attributes briefly rather than say "here's the
inspect module, it uses magic".

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

Re: inspecting a callable for the arguments it accepts

[Gregory Ewing]

Chris Angelico wrote:


wants_one_arg.__code__.co_argcount


1


wants_one_arg.__code__.co_varnames


('x',)


That will give you some idea, but it's not foolproof -- e.g.
if the function has * or ** arguments, it's impossible to tell
in general how many arguments it accepts without studying the
code (and maybe not even then -- halting problem, etc.)

Some of the co_flags seem to indicate presence of * and **:

0x04 - has *args
0x08 - has **kwds

In Py3 there is also co_kwonlyargcount.

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

[issue32021] Brotli encoding is not recognized by mimetypes

[Andrey]

Andrey  added the comment:

NodeJS: https://www.npmjs.com/package/brotli
Python:
https://pypi.python.org/pypi/brotlipy
https://pypi.python.org/pypi/Brotli
Ubuntu: https://launchpad.net/ubuntu/+source/brotli

That said I don't expect an average user to compress their files as .br, but it 
is useful for site/webapp developers to have static resources as .br

--

___
Python tracker 

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

[issue32030] PEP 432: Rewrite Py_Main()

[Nick Coghlan]

Nick Coghlan  added the comment:

While it doesn't necessarily need to be in this patch, something else I 
recently realised (by breaking it *cough* [1]) is that the interaction between 
our command line options and our environment variables isn't really clearly 
defined anywhere.

https://github.com/python/cpython/commit/d7ac06126db86f76ba92cbca4cb702852a321f78
 restored the handling of simple on/off toggles as "toggle enabled = env var is 
set OR CLI flag is passed", but I noticed the other day that the interaction 
between PYTHONWARNINGS, the `-W` option, sys.warnoptions, and _warnings.filters 
is a bit confusing:

```
$ PYTHONWARNINGS=always,default python3 -Wignore -Wonce
Python 3.6.2 (default, Oct  2 2017, 16:51:32) 
[GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, _warnings
>>> sys.warnoptions
['always', 'default', 'ignore', 'once']
>>> [f[0] for f in _warnings.filters[:4]]
['once', 'ignore', 'default', 'always']
```

The ordering makes *sense* (where sys.warnoptions just lists filter definitions 
in the order they're given, and later filters take priority over earlier ones, 
just as they do for any "warnings.filterwarnings" call), but it isn't 
immediately intuitive (since the outcome relies on filters being prepended by 
default).

That said, I've checked and the current warnings configuration behaviour *is* 
explicitly covered by the test suite (in 
https://github.com/python/cpython/blob/master/Lib/test/test_warnings/__init__.py),
 so a passing test suite provides confidence we haven't broken anything on that 
front.

[1] https://bugs.python.org/issue31845

--

___
Python tracker 

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

[issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition

[Sebastian Rittau]

Change by Sebastian Rittau :


--
nosy: +srittau

___
Python tracker 

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

[issue32025] Add time.thread_time()

[STINNER Victor]

STINNER Victor  added the comment:

It seems like macOS doesn't implement CLOCK_THREAD_CPUTIME_ID but provides 
thread_info() which can be used by suming user and system times.

--

___
Python tracker 

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

[issue32029] cgi: TypeError when no argument string is found

[Berker Peksag]

Berker Peksag  added the comment:

Thank you for your report. This looks like a duplicate of issue 2. You 
might workaround this by passing ``headers={"Content-Disposition": "inline"}`` 
to cgi.FieldStorage() (untested)

--
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> cgi.FieldStorage can't parse simple body with Content-Length 
and no Content-Disposition
type:  -> behavior

___
Python tracker 

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

Re: inspecting a callable for the arguments it accepts

[Cameron Simpson]

On 15Nov2017 09:12, Chris Angelico  wrote:

On Wed, Nov 15, 2017 at 8:05 AM, Cameron Simpson  wrote:

I know that this isn't generally solvable, but I'm wondering if it is
partially solvable.

I have a task manager which accepts callables, usually functions or
generators, and calls them on data items as needed. For reasons which,
frankly, suggest user interface ergonomics failure to me it happens that
inappropriate functions get submtted to this system. For example, functions
accepting no arguments but which are handed one by the system.

I would like to inspect submitted functions' signatures for suitability at
submission time, without calling the function. For example to see if this
function accepts exactly one argument, or to see if it is a generator, etc.

Is this possible, even in a limited way?


Yes, it is. Sometimes in a very limited way, other times fairly well.
(NOTE: I'm using CPython for this. Other interpreters may differ
wildly.)


I'm using CPython too.


First off, you can look at the function's attributes to see
some of the info you want:


def wants_one_arg(x): pass

...

wants_one_arg.__code__.co_argcount

1

wants_one_arg.__code__.co_varnames

('x',)

co_varnames has the names of all local variables, and the first N of
those are the arguments. You aren't matching on the argument names,
but they might help you make more readable error messages.

As to recognizing generators, every function has a set of flags which
will tell you whether it yields or just returns:


def fun(): pass

...

def gen(): yield 1

...

fun.__code__.co_flags

67

gen.__code__.co_flags

99

That's the raw info. For human-friendly functions that look at this
info, check out the inspect module:


inspect.isgeneratorfunction(fun)

False

inspect.isgeneratorfunction(gen)

True

inspect.signature(wants_one_arg)



Poke around with its functions and you should be able to find most of
what you want, I think.


Thank you, looks like just what I need.

Cheers,
Cameron Simpson  (formerly c...@zip.com.au)
--
https://mail.python.org/mailman/listinfo/python-list

[issue32025] Add time.thread_time()

[STINNER Victor]

STINNER Victor  added the comment:

> On other platforms, it can simply raise NotImplementedError.

Would it be possible to not provide the function if it's not supported by a 
platform?

Do you know platforms which don't support time.thread_time()?

Do you want to add time.thread_time_ns() with nanosecond resolution (PEP 564) ? 
I suggest to add it to be consistent with time.process_time().

--

___
Python tracker 

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

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

STINNER Victor  added the comment:

I rewrote Py_Main() to prepare the code to be able to implement my "-X dev" 
idea:
https://mail.python.org/pipermail/python-dev//2017-November/150514.html

The problem is that currently the code parsing command line options and the 
code setting the memory allocator (handle PYTHONMALLOC environment variable) 
are mixed, it's not possible to touch this code.

I had similar technical issues when trying to implement properly my PEP 540 
idea (Add a new UTF-8 mode): it's hard to change the Python filesystem encoding 
to UTF-8 after parsing command line arguments, since the current code to parse 
command line arguments already rely on the Python filesystem encoding and other 
parts of the Python runtime like the memory allocators.

If I implemented my PR correctly, it should become much more simpler to control 
PYTHONMALLOC and the filesystem encoding from the command line: from an -X 
option.

--

___
Python tracker 

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

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +eric.snow, ncoghlan

___
Python tracker 

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

[issue32030] PEP 432: Rewrite Py_Main()

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

Change by STINNER Victor :


--
title: Rewrite Py_Main() -> PEP 432: Rewrite Py_Main()

___
Python tracker 

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

[issue32030] Rewrite Py_Main()

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +4347
stage:  -> patch review

___
Python tracker 

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

[issue32030] Rewrite Py_Main()

[STINNER Victor]

New submission from STINNER Victor :

Python has a lot of code for its initialization. It's very hard to touch this 
code without risking to break something. It's hard to move code since many 
parts of the code are interdepent. The code rely on global "Py_xxx" 
configuration variables like Py_IsolateFlag (set by -I command line option).

Moreover, currently Python uses the "Python runtime" early. For example, the 
code to parse the -W command line option uses PyUnicode_FromWideChar() and 
PyList_Append(). We need a stricter separation for the code before the "Python 
runtime" is initialized, at least partially initialized.

Nick Coghlan and Eric Snow are already working on all these issues as part of 
the implementation of PEP 432. They redesigned Py_Initialize() and 
Py_Finalize().

I would like to finish the work on the step before: the Py_Main() function.

Attached PR is a work-in-progress to rework deeply the Py_Main() function. I 
have different goals:

* Enhance error handling:

  * Avoid whenever possible calls to Py_FatalError() -- currently, 
Py_FatalError() is still called, but at a single place
  * My patch adds missing checks on PyDict_SetItem() or PyList_Append() calls, 
catch errors when adding warnings options and XOptions

* Reorder code to initialize: initialize Python in the "correct" order
* Better "finalization": pymain_free() is now responsible to free memory of all 
data used by Py_Main(). The ownership of strings is now better defined. For 
example, Py_SetProgramName() memory was not released before.
* pymain_init() is now the code which must not use the Python runtime
* pymain_core() uses the Python runtime. Its code to initialize the Python 
runtime should be easier to follow

 
Since pymain_free() now wants to release the memory, we need to force a memory 
allocator for PyMem_RawMalloc(), since pymain_core() changes the memory 
allocator. The main() already does something similar, but with simpler code 
since main() is a private function, whereas Py_Main() seems to be part of the 
public C API!

--
messages: 306245
nosy: haypo
priority: normal
severity: normal
status: open
title: Rewrite Py_Main()
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

[issue32029] cgi: TypeError when no argument string is found

[Sebastian Rittau]

Change by Sebastian Rittau :


--
components: +Library (Lib)
title: cgi: TypeError -> cgi: TypeError when no argument string is found

___
Python tracker 

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

[issue32029] cgi: TypeError

[Sebastian Rittau]

New submission from Sebastian Rittau :

Consider the following code:

import cgi
from io import BytesIO

cgi.FieldStorage(BytesIO(b"{}"), environ={
"REQUEST_METHOD": "POST",
"CONTENT_TYPE": "application/json",
"CONTENT_LENGTH": "14",
})

This will throw the following exception:

Traceback (most recent call last):
  File "foo.py", line 7, in 
"CONTENT_LENGTH": "14",
  File "/usr/lib/python3.6/cgi.py", line 561, in __init__
self.read_single()
  File "/usr/lib/python3.6/cgi.py", line 740, in read_single
self.read_binary()
  File "/usr/lib/python3.6/cgi.py", line 762, in read_binary
self.file.write(data)
TypeError: write() argument must be str, not bytes

Of course, the input does not contain any argument string to be parsed by 
FieldStorage. Nevertheless, a TypeError in a totally unrelated part of the code 
seems like a bug. In my opinion, FieldStorage should just remain empty in this 
case, or - at best - throw a ValueError with a sensible error message.

--
messages: 306244
nosy: srittau
priority: normal
severity: normal
status: open
title: cgi: TypeError
versions: Python 3.6

___
Python tracker 

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

[issue31948] [EASY] Broken MSDN links in msilib docs

[Mariatta Wijaya]

Change by Mariatta Wijaya :


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

[issue31948] [EASY] Broken MSDN links in msilib docs

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:


New changeset 42336def77f53861284336b3335098a1b9b8cab2 by Mariatta 
(Jesse-Bakker) in branch '3.6':
bpo-31948: Fix broken links in msilib docs (GH-4397). (GH-4398)
https://github.com/python/cpython/commit/42336def77f53861284336b3335098a1b9b8cab2


--

___
Python tracker 

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

Re: inspecting a callable for the arguments it accepts

[Chris Angelico]

On Wed, Nov 15, 2017 at 9:03 AM, Stefan Ram  wrote:
> Cameron Simpson  writes:
>>I would like to inspect submitted functions' signatures for suitability at
>>submission time, without calling the function. For example to see if this
>>function accepts exactly one argument, or to see if it is a generator, etc.
>
>   Sometimes, there is a __text__signature__:
>
> |>>> cos.__text_signature__
> |'($module, x, /)'
>
>   , but not always.

True. However, I'm pretty sure that applies only to Argument Clinic
functions, which are all implemented in C; the context suggests that
the functions in question will all be implemented in Python.

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

Re: Time travel - how to simplify?

[Rick Johnson]

On Tuesday, November 14, 2017 at 1:44:17 PM UTC-6, Ben Finney wrote:
> Andrew Z  writes:
> 
> > Now i want to get certain number of months. Say, i need  3 months duration
> > starting from any month in dict.
> >
> > so if i start @ 7th:
> > my_choice =7
> >  for mnth, value in fut_suffix:
> > if my_choice >= mnth
> ># life is great
> > but if :
> > my_choice = 12 then my "time travel" becomes pain in the neck..
> 
> The ‘itertools’ library in the Python standard library
>  has what you
> need:
> 
> import itertools
> 
> month_values = sorted(list(fut_suffix.keys()))
> month_cycle = itertools.cycle(month_values)
> 
> month_choice = 7
> three_months_starting_at_choice = []
> while len(three_months_starting_at_choice) < 3:
> this_month = next(month_cycle)
> if this_month >= month_choice:
> three_months_starting_at_choice.append(this_month)

Ben's advice is spot on[1], and exactly what i would do, but
i believe it's important for you to discover how to
implement a simple cycling algorithm yourself, _before_
reaching for the pre-packaged junkfood in the itertools
module. Can you do it? If not, then do as much as you can
and then ask for help. Hey, you're only hurting yourself if
you don't learn how. And it's surprisingly easy!

[1] and it looks as though he included the kitchen sink,
washcloths, dish soap, and some fine china as well! ಠ_ಠ
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Windows10 keyboard interupt

[Lawrence D’Oliveiro]

On Wednesday, November 15, 2017 at 3:01:37 AM UTC+13, Kasper Jepsen wrote:

> Forgot.. python 2.7


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

[issue31948] [EASY] Broken MSDN links in msilib docs

[Jesse Bakker]

Change by Jesse Bakker :


--
pull_requests: +4346
stage: backport needed -> patch review

___
Python tracker 

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

[issue31948] [EASY] Broken MSDN links in msilib docs

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

This couldn't be backported by miss-islington, so someone needs to do it 
manually.

--
stage: patch review -> backport needed

___
Python tracker 

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

[issue31948] [EASY] Broken MSDN links in msilib docs

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:


New changeset 3bda0aa3783bf85fc3ff8bc042aefd9c4fd3 by Mariatta 
(Jesse-Bakker) in branch 'master':
bpo-31948: Fix broken links in msilib docs (GH-4397)
https://github.com/python/cpython/commit/3bda0aa3783bf85fc3ff8bc042aefd9c4fd3


--
nosy: +Mariatta

___
Python tracker 

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

[issue31948] [EASY] Broken MSDN links in msilib docs

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +4345
stage: needs patch -> patch review

___
Python tracker 

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

Re: inspecting a callable for the arguments it accepts

[Chris Angelico]

On Wed, Nov 15, 2017 at 8:05 AM, Cameron Simpson  wrote:
> I know that this isn't generally solvable, but I'm wondering if it is
> partially solvable.
>
> I have a task manager which accepts callables, usually functions or
> generators, and calls them on data items as needed. For reasons which,
> frankly, suggest user interface ergonomics failure to me it happens that
> inappropriate functions get submtted to this system. For example, functions
> accepting no arguments but which are handed one by the system.
>
> I would like to inspect submitted functions' signatures for suitability at
> submission time, without calling the function. For example to see if this
> function accepts exactly one argument, or to see if it is a generator, etc.
>
> Is this possible, even in a limited way?

Yes, it is. Sometimes in a very limited way, other times fairly well.
(NOTE: I'm using CPython for this. Other interpreters may differ
wildly.) First off, you can look at the function's attributes to see
some of the info you want:

>>> def wants_one_arg(x): pass
...
>>> wants_one_arg.__code__.co_argcount
1
>>> wants_one_arg.__code__.co_varnames
('x',)

co_varnames has the names of all local variables, and the first N of
those are the arguments. You aren't matching on the argument names,
but they might help you make more readable error messages.

As to recognizing generators, every function has a set of flags which
will tell you whether it yields or just returns:

>>> def fun(): pass
...
>>> def gen(): yield 1
...
>>> fun.__code__.co_flags
67
>>> gen.__code__.co_flags
99

That's the raw info. For human-friendly functions that look at this
info, check out the inspect module:

>>> inspect.isgeneratorfunction(fun)
False
>>> inspect.isgeneratorfunction(gen)
True
>>> inspect.signature(wants_one_arg)


Poke around with its functions and you should be able to find most of
what you want, I think.

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

[issue31997] SSL lib does not handle trailing dot (period) in hostname or certificate

[Christian Heimes]

Christian Heimes  added the comment:

As I explained before, the ssl module is the wrong place to address the issue. 
You *must* keep SNI TLS extension, HTTP Host header, and hostname for SAN 
matching in sync. Python uses the server_hostname argument for both SNI and 
hostname verification.

The issue must be solved in HTTP layer because the HTTP layer is the only place 
that can affect the HTTP Host header and SNI.

OpenSSL and NSS (Firefox's crypto and TLS lib) agree with me. Both don't like 
trailing dots in hostname either. BoringSSL's hostname verification code is 
based on OpenSSL's code. I'm pretty sure that Chrome handles trailing dot in a 
different layer, not in the actual TLS and X.509 handler. Ryan merely said that 
Chrome supports hostnames with trailing dot, not BoringSSL.

$ /usr/lib64/nss/unsupported-tools/vfyserv www.python.org
Connecting to host www.python.org (addr 151.101.112.223) on port 443
Handshake Complete: SERVER CONFIGURED CORRECTLY
   bulk cipher AES-128-GCM, 128 secret key bits, 128 key bits, status: 1
   subject DN:
 CN=www.python.org,O=Python Software Foundation,L=Wolfeboro,ST=New 
Hampshire,C=US,postalCode=03894-4801,STREET=16 Allen 
Rd,serialNumber=3359300,incorporationState=Delaware,incorporationCountry=US,businessCategory=Private
 Organization
   issuer  DN:
 CN=DigiCert SHA2 Extended Validation Server CA,OU=www.digicert.com,O=DigiCert 
Inc,C=US
   0 cache hits; 0 cache misses, 0 cache not reusable
* Connection 1 read 518 bytes total.

$ /usr/lib64/nss/unsupported-tools/vfyserv www.python.org.
Connecting to host www.python.org. (addr 151.101.112.223) on port 443
Error in function PR_Write: -12276
 - Unable to communicate securely with peer: requested domain name does not 
match the server's certificate.


$ openssl s_client -servername www.python.org -verify_hostname www.python.org 
-connect www.python.org:443
...
SSL handshake has read 4204 bytes and written 403 bytes
Verification: OK
Verified peername: www.python.org
...

$ openssl s_client -servername www.python.org. -verify_hostname www.python.org. 
-connect www.python.org.:443
...
SSL handshake has read 4204 bytes and written 404 bytes
Verification error: Hostname mismatch
...

--

___
Python tracker 

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

[issue32021] Brotli encoding is not recognized by mimetypes

[R. David Murray]

R. David Murray  added the comment:

Hmm. OK, the docs do say that value should be usable as a content-encoding 
header.

However, absent any sort of program that actually does brotli encoding/decoding 
to and from files, this would be essentially useless based on the aiohttp's 
algorithm (or any other use I can think of for the mimetimes module in this 
context).  Does such a program exist?  I didn't find one searching the web.

--

___
Python tracker 

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

inspecting a callable for the arguments it accepts

[Cameron Simpson]

I know that this isn't generally solvable, but I'm wondering if it is partially 
solvable.


I have a task manager which accepts callables, usually functions or generators, 
and calls them on data items as needed. For reasons which, frankly, suggest 
user interface ergonomics failure to me it happens that inappropriate functions 
get submtted to this system. For example, functions accepting no arguments but 
which are handed one by the system.


I would like to inspect submitted functions' signatures for suitability at 
submission time, without calling the function. For example to see if this 
function accepts exactly one argument, or to see if it is a generator, etc.


Is this possible, even in a limited way?

The present situation is that when I get this wrong I get highly cryptic 
exceptions at runtime, some of which I think I could be FAR better understood 
if caught at submittion time.


Here's an example failure at runtime:

   pilfer.py: WorkerThreadPool:Later-1:WorkerThreadPool: worker thread: ran task: exception! 
(, TypeError('() takes 0 positional arguments but 1 was 
given',), )
   Traceback (most recent call last):
 File "/Users/cameron/hg/css/cs/threads.py", line 163, in _handler
   result = func()
 File "/Users/cameron/hg/css/cs/app/pilfer.py", line 1550, in retry_func
   return func(P, *a, **kw)
   TypeError: () takes 0 positional arguments but 1 was given
   pilfer.py: MAIN:0:0:retriable().put(Pilfer-0[http://www.smh.com.au/]): (, TypeError('() takes 0 positional arguments but 1 was given',), 
)

Ignoring the slight repetition you can see that (a) there's no direct clue as 
to what the actual submitted function was originally, as it is a lambda and (b) 
there's no direct clue as to where the function came from, because the 
submission call stack is long gone and the function is being called via a 
thread pool.


Had I caught the function as unsuitable at submission time, debugging would be 
far easier.


To be clear: the task manager is my own project, as is the submitted function.  
I'm trying to improve its debuggability.


Cheers,
Cameron Simpson  (formerly c...@zip.com.au)
--
https://mail.python.org/mailman/listinfo/python-list

Re: from xx import yy

[Cameron Simpson]

On 13Nov2017 08:58, bvdp  wrote:

On Sunday, November 12, 2017 at 7:18:04 PM UTC-7, bvdp wrote:

I'm having a conceptual mind-fart today. I just modified a bunch of code to use 
"from xx import variable" when variable is a global in xx.py. But, when I 
change/read 'variable' it doesn't appear to change. I've written a bit of code to show 
the problem:

mod1.py
myvar = 99
def setvar(x):
global myvar
myvar = x

test1.py
import mod1
mod1.myvar = 44
print (mod1.myvar)
mod1.setvar(33)
print (mod1.myvar)

If this test1.py is run myvar is fine. But, if I run:

test2.py
from mod1 import myvar, setvar
myvar = 44
print (myvar)
setvar(33)
print (myvar)

It doesn't print the '33'.

I thought (apparently incorrectly) that import as would import the name myvar 
into the current module's namespace where it could be read by functions in the 
module


Thanks all for confirming that I was wrong to use "from .. import". Hmmm, 
perhaps for functions it might be okay. But, in most cases it's a lot more obvious to use 
module.function() when calling. Maybe a bit slower, but I'm sure it's negligible in most 
cases.


You're wrong to use it for this particular special case, and ony because you 
lose the reference to the module itself, which means you're no longer accessing 
the _reference_ "mod1.myvar", you're accessing a copy of the reference. So the 
wrong reference gets changed.


In the general case, this isn't something people do a great deal. For most 
imports you want access to things from the module with no intention of changing 
those references in the source module.


So "from xx import yy" is perfectly find for that, the most common use case.

Consider:

 from os.path import basename, dirname

Is your code more readable with:

 from os.path import basename, dirname
 base_of_parent_dir = basename(dirname(some_path))

or as:

 import os.path
 base_of_parent_dir = os.path.basename(os.path.dirname(some_path))

particularly when you make lots of such calls? I much prefer the former.

And, yes, I am trying to share state info between modules. Is this a bad 
thing? I guess I would write getter() and setter() functions for all this. But 
that does seem to remind me too much of some other language :)


In controlled situations it can be ok. Usually I define a small class for this 
kind of thing and keep all the state in class instances. That way it can scale 
(keeping multiple "states" at once).


However, it does depend on your particular situation. I find situations where I 
want to directly change "global" values in other modules very rare, though not 
unknown.


Cheers,
Cameron Simpson  (formerly c...@zip.com.au)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Time travel - how to simplify?

[Ben Finney]

Ben Finney  writes:

> import itertools
>
> month_values = sorted(list(fut_suffix.keys()))
> month_cycle = itertools.cycle(month_values)
>
> month_choice = 7
> three_months_starting_at_choice = []
> while len(three_months_starting_at_choice) < 3:
> this_month = next(month_cycle)
> if this_month >= month_choice:
> three_months_starting_at_choice.append(this_month)

Sorry, I now realise that won't do what you want; the wrap around from
12 to 1 will cause ‘this_month >= month_choice’ to be false.

Well, I won't correct it; maybe this is a useful exercise. Do you have a
way to fix that so it will work?

-- 
 \  “I am too firm in my consciousness of the marvelous to be ever |
  `\   fascinated by the mere supernatural …” —Joseph Conrad, _The |
_o__) Shadow-Line_ |
Ben Finney

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

[issue31997] SSL lib does not handle trailing dot (period) in hostname or certificate

[Sam Napolitano]

Sam Napolitano  added the comment:

Sorry I wasn't able to get back to you sooner.

If having a trailing dot in the cert is an RFC violation, then case 2 can be 
left alone.

As for case 3, we can be more explicit:  if hostname ends in a dot AND cert 
does not end in a dot, strip dot from hostname.  This seems to be what Ryan was 
saying Chrome does.

I did a test using s_client in openssl.  Testing all 4 cases in the truth table 
returned 200s.  

$ openssl s_client -connect www.google.com.:443
...
# Enter next two lines and press return twice
HEAD / HTTP/1.0
Host: www.google.com.

# Returns 200
HTTP/1.0 200 OK
Date: Sat, 11 Nov 2017 21:20:44 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
...

So it would appear openssl against Google handles dots ok, but I could be 
wrong.  I don't know what server software they are running.

As for testing other server ssl implementations what are you looking for? 

I found a small C openssl client implementation.

https://ubuntuforums.org/showthread.php?t=2217101=12989750#post12989750

Compiling that code with some minor tweaks against openssl and testing it with 
different hostnames and Host headers (dot and no dot), the ssl connection was 
established and data read.  Invalid constructs led to errors.

Yes, you could move the logic to urllib, but I'm not sure it's practical as 
many folks just expect the ssl lib to handle the nuances.  If users have to 
handle it themselves or include urllib, it seems like an extra lift.

I appreciate you taking the time to consider the issue.

--

___
Python tracker 

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

[issue31963] AMD64 Debian PGO 3.x buildbot: compilation failed with an internal compiler error in create_edge

[Neil Schemenauer]

Neil Schemenauer  added the comment:

I'm willing to put some time into trying to fix this, in the case that it is 
caused by my Makefile changes.  However, it would be very helpful if I could 
login to the build-bot and try running with the Makefile change backed out.  Is 
that possible?  Having to setup a VM to match the compiler of the build-bot 
would take quite a bit a of extra time.

Looking at the "stdout" log file, I can't see that we are doing anything wrong. 
 Specifically, the ".gc??" files are being removed and so I think that rules 
out the theory of stale profile information files messing up GCC.

--

___
Python tracker 

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

Re: Time travel - how to simplify?

[Ben Finney]

Andrew Z  writes:

> Now i want to get certain number of months. Say, i need  3 months duration
> starting from any month in dict.
>
> so if i start @ 7th:
> my_choice =7
>  for mnth, value in fut_suffix:
> if my_choice >= mnth
># life is great
> but if :
> my_choice = 12 then my "time travel" becomes pain in the neck..

The ‘itertools’ library in the Python standard library
 has what you
need:

import itertools

month_values = sorted(list(fut_suffix.keys()))
month_cycle = itertools.cycle(month_values)

month_choice = 7
three_months_starting_at_choice = []
while len(three_months_starting_at_choice) < 3:
this_month = next(month_cycle)
if this_month >= month_choice:
three_months_starting_at_choice.append(this_month)

-- 
 \  “God forbid that any book should be banned. The practice is as |
  `\  indefensible as infanticide.” —Dame Rebecca West |
_o__)  |
Ben Finney

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

[issue32023] Always require parentheses for genexps in base class lists

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
dependencies: +Disallow ambiguous syntax f(x for x in [1],)

___
Python tracker 

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

[issue32024] Nominal decorator function call syntax is inconsistent with regular function calls

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
dependencies: +Disallow ambiguous syntax f(x for x in [1],)
type: behavior -> enhancement
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

[issue27923] PEP 467 -- Minor API improvements for binary sequences

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I don't think these changes should be merged.

For bytes.zeros(N), you can use b'\0' * N.

For iterbytes() methods, I think that the general function which works with any 
sequence that support slicing would be more useful.

--

___
Python tracker 

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

[issue32027] argparse allow_abbrev option also controls short flag combinations

[Jörn Hees]

Change by Jörn Hees :


--
keywords: +patch
pull_requests: +4344
stage:  -> patch review

___
Python tracker 

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

[issue27923] PEP 467 -- Minor API improvements for binary sequences

[Elias Zamaria]

Elias Zamaria  added the comment:

Can someone here merge my pull request? If not, then what else needs to be done 
for my change to be included in 3.7?

--

___
Python tracker 

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

[issue32024] Nominal decorator function call syntax is inconsistent with regular function calls

[Guido van Rossum]

Guido van Rossum  added the comment:

The implementation is as intended and the language spec needs an update.

--

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Guido van Rossum]

Guido van Rossum  added the comment:

It's a (small) mistake that we didn't make the syntax for argument lists in 
decorators the same as argument lists everywhere else, and that should be fixed 
to allow exactly what's allowed in regular calls. (That syntax is weird because 
we don't want e.g. `@foo().bar` but we do want e.g. `@foo.bar()`.)

I am honestly not sure that we should change anything here, since the meaning 
is not actually ambiguous: the syntax for generator expressions doesn't allow 
e.g. `x for x in 1, 2, 3` -- you have to write `x for x in (1, 2, 3)`. (A 
regular for-loop *does* allow this, but there the context makes it unambiguous 
-- that's why genexprs are different.)

But I'm fine with changing it, as long as we do it consistently.

--

___
Python tracker 

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

[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers

[Yury Selivanov]

Yury Selivanov  added the comment:

> The bugfix could be backported to Python 3.6 but I very not sure about the 
> need for 3.5.
> It is a desirable fix but not secure.

The attached script looks very innocent, and it's worrisome that it's that easy 
to make an asyncio SSL server to leak sockets in some contexts.  I think it's 
OK to fix 3.5, but let's make the final decision when we have an approved PR.

I merged Nick's PR once, but then it introduced some problems on buildbots 
(https://bugs.python.org/msg295659), so I reverted the commit.

I'd suggest to look at the attached script again (scratch_1.py) and try to 
understand what exactly causes the problem with that specific Apache server 
version.  I'd also suggest to come up with a *functional* unittest that 
reproduces it (you can grab some testing utilities from the uvloop project).

--

___
Python tracker 

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

[issue32028] Syntactically wrong suggestions by the new custom print statement error message

[Martin Drawitsch]

New submission from Martin Drawitsch :

I think I found a bug in the new print syntax suggestion introduced by 
https://bugs.python.org/issue30597.


When the following code is executed by Python 3.6.3 inside of a .py file:

def f():
print '%d' % 2

, then Python gives the following error message:

SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int 
'%d' % 2)?

The "int" next to the left brace of the suggested print function is obviously 
wrong.
The expected message would be:

SyntaxError: Missing parentheses in call to 'print'. Did you mean 
print('%d' % 2)?

Using other values or "%s" in the formatted string in a print statement 
produces the same wrong message.
This bug only seems to happen when the print statement is inside of a function 
AND when it is is run inside of a .py file. At least I could not reproduce it 
in the python3 REPL or outside of a function.

I am attaching the minimal example file in this bug report. Running it with "$ 
python3 print.py" should show the mentioned bug.

--
components: Interpreter Core
files: print.py
messages: 306231
nosy: CuriousLearner, mdraw, ncoghlan
priority: normal
severity: normal
status: open
title: Syntactically wrong suggestions by the new custom print statement error 
message
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47265/print.py

___
Python tracker 

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

[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I'm skeptical about `critical` priority.

The bugfix could be backported to Python 3.6 but I very not sure about the need 
for 3.5.
It is a desirable fix but not secure.

Yury Selivanov please confirm.

--

___
Python tracker 

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

[issue32027] argparse allow_abbrev option also controls short flag combinations

[Jörn Hees]

New submission from Jörn Hees :

The allow_abbrev option (default True) currently is documented like this 
(https://docs.python.org/3/library/argparse.html#allow-abbrev):
> Normally, when you pass an argument list to the parse_args() method of an 
> ArgumentParser, it recognizes abbreviations of long options.

However, it also controls combinations of short options and especially the 
combination of flags (store_const) like `-a -b` as `-ab`.

Example snippet for testing:

import argparse
import sys

parser = argparse.ArgumentParser(
allow_abbrev=False
)
parser.add_argument('-a', action='store_true')
parser.add_argument('-b', action='store_true')
parser.add_argument('x', nargs='*')
parser.parse_args('-a -b foo bar'.split())
parser.parse_args('-ab foo bar'.split())


As you can see the 2nd parse will fail if allow_abbrev=False.

This issue is either a doc issue only or an unintended combination of long 
option shortening and (the way more common) flag combinations. When i 
deactivated this in my code, i wanted to disable the (nice to have) long option 
shortening, but i unintentionally also deactivated (MUST have) short flag 
combinations.

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 306229
nosy: docs@python, joern
priority: normal
severity: normal
status: open
title: argparse allow_abbrev option also controls short flag combinations
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I'm picking up the issue.
Will provide an updated PR soon.

--
assignee: yselivanov -> asvetlov
nosy: +asvetlov

___
Python tracker 

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

[issue32026] Memory leaks in Python on Windows

[PJ Naughter]

PJ Naughter  added the comment:

OK, Thanks for the quick reply. I have just migrated my application from Python 
3.3 to Python 3.6.3 and would not expect you to backport changes from the 3.7 
development stream to the released stream. What I will do when I get a chance 
is pull down the 3.7 sources and compare the demo app I have produced with 3.7 
vs 3.6.3 to see if improvements have been done in this area.

--

___
Python tracker 

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

[issue32021] Brotli encoding is not recognized by mimetypes

[Andrey]

Andrey  added the comment:

Currently aiohttp doesn't support Brotli. (I'm here because I would like to get 
that support)

When it gets (as a server) a request for file.html it checks if file.html.gz 
exists (and accept-encoding contains 'gzip'). It then send file.html.gz to the 
client and sets Content-Encoding to gzip.

It uses mimetypes.guess_type to set Content-Type and Content-Encoding.

--

___
Python tracker 

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

[issue32026] Memory leaks in Python on Windows

[Steve Dower]

Steve Dower  added the comment:

Not sure how much we can do about this, but you may want to try with Python 
3.7. Eric and Nick have been working on streamlining startup, which includes a 
lot of work (thanks Eric!) to remove static variables.

Don't expect a fix in Python 3.6 for this, and don't be surprised if Eric/Nick 
closes this and references whichever bug they're using to track the other work, 
but it is something that we're aware of and are (slowly) working to address.

--
nosy: +eric.snow, ncoghlan
versions: +Python 3.7 -Python 3.6

___
Python tracker 

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

[issue31388] Provide a way to defer SIGINT handling in the current thread

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

It's not only about ensuring that cleanup code gets run, but also about 
ensuring that the interrupt is actually seen. Currently, if you press CTRL-C at 
the "wrong" moment (during __del__), it will just get ignored.

--
nosy: +jdemeyer

___
Python tracker 

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

Re: PySide window does not resize to fit screen

[Heli]

Hi Chris and others, 

I have re-designed my user interface to include layouts and now it fits the 
screen perfectly.

Thanks a lot for all your help on this thread, 
Best 
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32026] Memory leaks in Python on Windows

[PJ Naughter]

New submission from PJ Naughter :

I would like to report memory leaks in Python 3.6.3 when embedded in a C++ 
Windows app. I have download the Python 3.6.3 code and compiled a debug version 
of Python with my copy of Visual Studio 2017 Professional (have also confirmed 
the problem in Visual Studio 2015 Professional) and built the debug version of 
the Python DLL. With the following sample app I get memory leaks when compiled 
in debug mode:


//Pull in the Windows header and the MSVC Debug C Runtime
#include 
#define _CRTDBG_MAP_ALLOC
#include 
#include 

//Pull in Python
#include  

int __stdcall WinMain(HINSTANCE /*hInstance*/, HINSTANCE /*hPrevInstance*/, 
_In_ LPTSTR /*lpCmdLine*/, int /*nCmdShow*/)
{
  //Track memory leaks using the MSVC Debug CRT
  _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
  //_CrtSetBreakAlloc(81);

  //Initialize Python
  Py_Initialize();
  PyEval_InitThreads();

  //Pretend this app does something!
  Sleep(2000);

  //Shutdown Python
  Py_FinalizeEx();
}

Taking out the calls to Py_Initialize, PyEval_InitThreads & Py_FinalizeEx 
results in no memory leaks being reported. The actual reported memory leaks are 
reported to the output window in Visual Studio as follows:

Detected memory leaks!
Dumping objects ->
{700} normal block at 0x014E0078, 2604 bytes long.
Data:  00 00 0A 1C 72 FB FB FB 00 00 0A 0C 6F FB FB FB
{ 698 } normal block at 0x01502148, 2604 bytes long.
Data :  00 00 0A 1C 72 FB FB FB 00 00 0A 0C 6F FB FB FB
{ 697 } normal block at 0x014DA350, 52 bytes long.
Data : <   $r   > 00 00 00 24 72 FB FB FB FF FF FF FF FF FF FF FF
{ 458 } normal block at 0x01511A88, 81968 bytes long.
Data : <  @ r @ o   > 00 01 40 20 72 FB FB FB 00 01 40 10 6F FB FB FB
{ 389 } normal block at 0x014F1270, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 359 } normal block at 0x014FA730, 5168 bytes long.
Data :  00 00 14 20 72 FB FB FB 00 00 14 10 6F FB FB FB
{ 319 } normal block at 0x014EE120, 2604 bytes long.
Data :  00 00 0A 1C 72 FB FB FB 00 00 0A 0C 6F FB FB FB
{ 315 } normal block at 0x014EC478, 1200 bytes long.
Data :  00 00 04 A0 72 FB FB FB 00 00 04 90 6F FB FB FB
{ 307 } normal block at 0x01500B98, 529 bytes long.
Data :  00 00 02 01 72 FB FB FB 00 00 01 F1 6F FB FB FB
{ 281 } normal block at 0x01500350, 709 bytes long.
Data :  00 00 02 B5 72 FB FB FB 00 00 02 A5 6F FB FB FB
{ 264 } normal block at 0x014FDAF8, 10284 bytes long.
Data : <  (r(o   > 00 00 28 1C 72 FB FB FB 00 00 28 0C 6F FB FB FB
{ 253 } normal block at 0x014F89F0, 539 bytes long.
Data :  00 00 02 0B 72 FB FB FB 00 00 01 FB 6F FB FB FB
{ 248 } normal block at 0x014F5448, 847 bytes long.
Data: < ? r / o   > 00 00 03 3F 72 FB FB FB 00 00 03 2F 6F FB FB FB
{ 247 } normal block at 0x014F0A78, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 235 } normal block at 0x014F2A58, 1409 bytes long.
Data : <   qr  ao   > 00 00 05 71 72 FB FB FB 00 00 05 61 6F FB FB FB
{ 234 } normal block at 0x014F1FB8, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 233 } normal block at 0x014F1A68, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 232 } normal block at 0x014F1518, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 231 } normal block at 0x014E2BE0, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 230 } normal block at 0x014EFFF8, 2604 bytes long.
Data :  00 00 0A 1C 72 FB FB FB 00 00 0A 0C 6F FB FB FB
{ 229 } normal block at 0x014EFD60, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 228 } normal block at 0x014EF9E8, 843 bytes long.
Data : <; r + o   > 00 00 03 3B 72 FB FB FB 00 00 03 2B 6F FB FB FB
{ 227 } normal block at 0x014EF750, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 226 } normal block at 0x014E4410, 561 bytes long.
Data : <   !r   o   > 00 00 02 21 72 FB FB FB 00 00 02 11 6F FB FB FB
{ 225 } normal block at 0x014EF1D0, 1360 bytes long.
Data : <   @r  0o   > 00 00 05 40 72 FB FB FB 00 00 05 30 6F FB FB FB
{ 224 } normal block at 0x014E49E0, 620 bytes long.
Data : <   \r  Lo   > 00 00 02 5C 72 FB FB FB 00 00 02 4C 6F FB FB FB
{ 206 } normal block at 0x014E3C88, 1200 bytes long.
Data :  00 00 04 A0 72 FB FB FB 00 00 04 90 6F FB FB FB
{ 205 } normal block at 0x014E3978, 734 bytes long.
Data :  00 00 02 CE 72 FB FB FB 00 00 02 BE 6F FB FB FB
{ 204 } normal block at 0x014E3358, 1521 bytes long.
Data :  00 00 05 E1 72 FB FB FB 00 00 05 D1 6F FB FB FB
{ 195 } normal block at 0x014E9890, 1553 bytes long.
Data 

[issue32021] Brotli encoding is not recognized by mimetypes

[R. David Murray]

R. David Murray  added the comment:

Note, I'm not saying we shouldn't do this, I'd just like to get good 
documentation of why linked to this issue.

--

___
Python tracker 

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

[issue32021] Brotli encoding is not recognized by mimetypes

[R. David Murray]

R. David Murray  added the comment:

OK, so there are "real" filenames that have .br on the end?  That wasn't clear 
from the RFC and discussions I found.  Based on the documentation, br is for 
use in the Content-Encoding header.

What does aiohttp do when it gets a brotli encoded file?  What does it do with 
the other types in the http content-encoding table? 
(https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding)

Where is the standard that talks about the '.br' file extension?

--

___
Python tracker 

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

[issue32022] Python problem - == RESTART: Shell =====

[Shimon Malachi Cohen]

Shimon Malachi Cohen  added the comment:

Here is another simple example - Simple? the game board ==> is small 
see attached PY file
run ==> doFind()

--
Added file: https://bugs.python.org/file47264/KAKURU.py

___
Python tracker 

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

[issue15606] re.VERBOSE whitespace behavior not completely documented

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset a2f1be0b5ba2bed49b7f94c026b541ff07e52518 by Serhiy Storchaka 
(Miss Islington (bot)) in branch '2.7':
bpo-15606: Improve the re.VERBOSE documentation. (GH-4366) (#4395)
https://github.com/python/cpython/commit/a2f1be0b5ba2bed49b7f94c026b541ff07e52518


--

___
Python tracker 

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

[issue31415] Add -X option to show import time

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I think there is nothing left to do for this issue, so I'm closing it.

--
status: open -> closed

___
Python tracker 

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

[issue15606] re.VERBOSE whitespace behavior not completely documented

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue15606] re.VERBOSE whitespace behavior not completely documented

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 14c1fe682f0086ec28f24fee9bf1c85d80507ee5 by Serhiy Storchaka 
(Miss Islington (bot)) in branch '3.6':
bpo-15606: Improve the re.VERBOSE documentation. (GH-4366) (#4394)
https://github.com/python/cpython/commit/14c1fe682f0086ec28f24fee9bf1c85d80507ee5


--

___
Python tracker 

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

[issue15606] re.VERBOSE whitespace behavior not completely documented

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4343

___
Python tracker 

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

[issue15606] re.VERBOSE whitespace behavior not completely documented

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4342

___
Python tracker 

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

[issue15606] re.VERBOSE whitespace behavior not completely documented

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset b0b44b4b3337297007f5ef87220a75df204399f8 by Serhiy Storchaka in 
branch 'master':
bpo-15606: Improve the re.VERBOSE documentation. (#4366)
https://github.com/python/cpython/commit/b0b44b4b3337297007f5ef87220a75df204399f8


--

___
Python tracker 

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

[issue32021] Brotli encoding is not recognized by mimetypes

[Andrey]

Andrey  added the comment:

When "type, encoding = mimetypes.guess_type('file.js.br')" is used not only the 
"encoding" is not set to "brotli", but the type is also not recognized.
Such code is used in aiohttp for example.

My proposal is to add 'br' to mimetypes.encodings_map, not to 
mimetypes.types_map

--

___
Python tracker 

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

[issue32022] Python problem - == RESTART: Shell =====

[Eric V. Smith]

Eric V. Smith  added the comment:

That's too much code for me to run without analyzing it first. If I have time, 
I'll look at it.

--

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Yury Selivanov]

Change by Yury Selivanov :


--
nosy:  -yselivanov

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Stefan Krah]

Change by Stefan Krah :


--
nosy:  -skrah

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Stefan Krah]

Stefan Krah  added the comment:

Yes Sir!

--
nosy: +skrah

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Stefan, `[1,2,3]` is an expression, but `x for x in [1,2,3]` is not. If you 
want to change the Python language specification, please open a topic on 
Python-Dev and provide the rationale.

--

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Stefan Krah]

Change by Stefan Krah :


--
nosy:  -skrah

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I would prefer to fix all related cases in one issue, for having all examples 
in one place and having only one reference. All this cases are caused by the 
limitation of the parser used in CPython, and using different grammar rules. 
This If you want to change the language specification for decorator expression 
and class definition, it should be discussed before merging PR 4382, and I 
would make corresponding changes in it. In any case it is harder to fix 
issue32023 without fixing the original issue.

--

___
Python tracker 

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

[issue32025] Add time.thread_time()

[Antoine Pitrou]

New submission from Antoine Pitrou :

Currently, the time module has time.process_time(), a cross-platform function 
for getting per-process elapsed CPU time.

Similarly, we could expose time.thread_time(), to get per-thread elapsed CPU 
time.
On a modern POSIX platform, it can use clock_gettime(CLOCK_THREAD_CPUTIME_ID).
On Windows, it can use GetThreadTimes(): 
https://msdn.microsoft.com/en-us/library/ms683237%28VS.85%29.aspx
On other platforms, it can simply raise NotImplementedError.

Currently, you would need ctypes hacks to call GetThreadTimes(), which is not 
very nice.

--
components: Library (Lib)
messages: 306210
nosy: belopolsky, haypo, pitrou
priority: normal
severity: normal
status: open
title: Add time.thread_time()
type: enhancement
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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Stefan Krah]

Stefan Krah  added the comment:

On Tue, Nov 14, 2017 at 01:31:52PM +, Nick Coghlan wrote:
> If limited to the original scope, this isn't a new special case, it's fixing 
> a bug in the implementation of the existing special case (where it's ignoring 
> the trailing comma when it shouldn't be).

This ignores the trailing comma:

f([1,2,3],)

And this:

f(x for x in [1,2,3],)

Seems logical to me.

Do you want to allow the 1,2 to be read as a tuple?

   f(x for x in 1,2)

--

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Nick Coghlan]

Nick Coghlan  added the comment:

If limited to the original scope, this isn't a new special case, it's fixing a 
bug in the implementation of the existing special case (where it's ignoring the 
trailing comma when it shouldn't be).

If it hadn't been for the scope creep to include a couple of other cases where 
the implementation is arguably more permissive than the language spec says it 
should, it would have already been merged.

--

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Stefan Krah]

Stefan Krah  added the comment:

I would prefer to do nothing about the subject of this issue. I still
don't see any ambiguity, except in a very broad colloquial sense.

Why introduce another special case?

--

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Nick Coghlan]

Nick Coghlan  added the comment:

OK, I've filed https://bugs.python.org/issue32024 to cover the decorator syntax 
discrepancy.

So I'd still prefer to restrict the patch for *this* issue to just the 
genuinely ambiguous case, and leave the 
unambiguous-but-inconsistent-with-the-language-spec cases to their respective 
issues.

--

___
Python tracker 

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

[issue32024] Nominal decorator function call syntax is inconsistent with regular function calls

[Nick Coghlan]

New submission from Nick Coghlan :

Function calls in decorators are implemented as regular function calls, and 
hence permit the use of generator expressions as their sole argument without a 
second pair of parentheses.

However, 
https://docs.python.org/3/reference/compound_stmts.html#function-definitions 
defines the permitted arguments differently from the way 
https://docs.python.org/3/reference/expressions.html#calls defines them, and 
thus technically considers a "function call as a decorator" to be a different 
construct from "a function call".

The actual implementation treats these as the same thing, so clarification is 
needed as to whether it is the implementation or the language specification 
that should be updated to resolve the inconsistency.

--
assignee: docs@python
components: Documentation
messages: 306205
nosy: docs@python, gvanrossum, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Nominal decorator function call syntax is inconsistent with regular 
function calls
type: behavior

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Stefan Krah]

Stefan Krah  added the comment:

I think "ambiguous" is not the right word. If a single argument
can be a non-parenthesized generator and all arguments can be
followed by a trailing comma, it's clear.

The language spec is often behind in my experience.

--
nosy: +skrah

___
Python tracker 

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

[issue32021] Brotli encoding is not recognized by mimetypes

[R. David Murray]

R. David Murray  added the comment:

It looks like Brotli is a de-facto standard (RFC 7932 is an informational RFC), 
and it says the IANA registry has been updated.  However, this appears to be 
http-only, with no corresponding program used for compression of files, and 
thus no "file extension" to be registered, or program name to put in the 
encodings_map table.  We don't have most of the types listed in the http 
content encodings registry in mimetypes, so I don't at this time see any reason 
to add br.

mimetypes is aimed at files, not http.  In what context do you want to use 
mimetimes to look up br?

--
nosy: +r.david.murray

___
Python tracker 

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

[issue32022] Python problem - == RESTART: Shell =====

[Shimon Malachi Cohen]

Shimon Malachi Cohen  added the comment:

Not really...
Did you see the "restart" ?

On Nov 14, 2017 2:38 PM, "Eric V. Smith"  wrote:

>
> Eric V. Smith  added the comment:
>
> Can you reproduce this with a much smaller example?
>
> --
> nosy: +eric.smith
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue32022] Python problem - == RESTART: Shell =====

[Eric V. Smith]

Eric V. Smith  added the comment:

Can you reproduce this with a much smaller example?

--
nosy: +eric.smith

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Henk-Jaap Wagenaar]

Henk-Jaap Wagenaar  added the comment:

I think this showcases how difficult it is to get this right, requires 
carefully reading the EBNF language spec, not just the text, and the behaviour 
is unexpected.

--

___
Python tracker 

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

Invitation to SciPy India 2017

[binson babu]

Dear All,

SciPy is near!!
To know more continue reading.



[image: scipy 2017]  [image: FOSSEE]

View this email in your browser


*Dear Sir / Madam,*

The FOSSEE  project based at IIT Bombay invites the
faculty, students and members of your institution/organization to SciPy
India 2017 .
[image: scipy 2017]  SciPy India 2017
--
NOVEMBER 29 & 30

SciPy India is an annual conference that is currently in its ninth year and
provides an opportunity to learn and use Python in education and research.
The conference will have basic and advanced workshops on Python and also
some interesting talks. For further information about SciPy India 2017,
visit http://scipy.in/2017. We look forward to your participation in SciPy
India 2017.

*Registration* for the conference is now open.
Register Now 
Lite ₹600 (Till 20th Nov 2017) Regular ₹1400 (26th Oct - 25th Nov 2017)

*Group Registration Discount:* For 5 or more registrations done together, a
20% discount shall be provided. The same will be applied automatically at
the time of registration.

[image: scipy poster 2017]

We request you to share the event details through this poster with faculty
members, students and others who might be interested. You may display the
poster on notice boards.

View Poster

Connect with Us:

Facebook  Twitter
 Google+ 
Contact Us:

scipy(at)fossee(dot)in 
info(at)fossee(dot)in 

Schedule  | Invited Speakers
 | Sponsors 
| Venue  | Unsubscribe

[image: IIT Bombay] 

[image: Valid XHTML 1.0 Transitional]


Regards,
Binson Babu
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

No, it doesn't match the "@dotted_name(arg_list)" pattern.

   decorator: "@" `dotted_name` ["(" [`argument_list` [","]] ")"] NEWLINE
   call: `primary` "(" [`argument_list` [","] | `comprehension`] ")"
   argument_list: `positional_arguments` ["," `starred_and_keywords`]
:   ["," `keywords_arguments`]
: | `starred_and_keywords` ["," `keywords_arguments`]
: | `keywords_arguments`

The call syntax contains a special case for generator expression. The decorator 
expression syntax dosn't contain it. You should change the grammar rule to

   decorator: "@" `dotted_name` ["(" [`argument_list` [","] | `comprehension`] 
")"] NEWLINE

for supporting this syntax. Please open a separate topic on Python-Dev for 
discussing this language change.

--

___
Python tracker 

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

[issue32012] Disallow ambiguous syntax f(x for x in [1],)

[Nick Coghlan]

Nick Coghlan  added the comment:

I created https://bugs.python.org/issue32023 to explicitly cover the base class 
list case, and after checking the language spec, I agree that case should be a 
syntax error.

However, `@deco(x for x in [])` should *not* be a syntax error, as:

* it's a call with one argument, so the genexp parentheses can be omitted as 
described in 
https://docs.python.org/3/reference/expressions.html#generator-expressions
* it matches the "@dotted_name(arg_list)" pattern permitted by 
https://docs.python.org/3/reference/compound_stmts.html#function-definitions

--

___
Python tracker 

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

[issue32023] Always require parentheses for genexps in base class lists

[Nick Coghlan]

New submission from Nick Coghlan :

The compiler currently allows parentheses to be omitted if a generator 
expression is the sole entry in a base class list:

>>> class C(x for x in []): pass
... 
Traceback (most recent call last):
  File "", line 1, in 
TypeError: cannot create 'generator' instances

The language reference states that the parentheses around a generator 
expression are only optional for "calls with only one argument": 
https://docs.python.org/3/reference/expressions.html#generator-expressions

A base class list is not a call, so this should be treated as a syntax error, 
rather than being handled as equivalent to `class C((x for x in [])): pass`

--
components: Interpreter Core
messages: 306197
nosy: ncoghlan, serhiy.storchaka
priority: low
severity: normal
status: open
title: Always require parentheses for genexps in base class lists
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

Re: for/ if against dict - one liner

[Thomas Jollans]

On 2017-11-14 06:44, Andrew Z wrote:
> Hello,
>  i wonder how do i get the "for" and "if" to work against a dictionary in
> one line?
> 
> basically i want to "squeeze":
>  dct= [ 1 : "one", 2:"two", 3:"three"]
>  for k, val in dct:

Don't you mean dct.items()

>if k >= 2:
>   # do magnificent things
> 
> Thank you
> AZ
> 


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

Re: for/ if against dict - one liner

[alister via Python-list]

On Tue, 14 Nov 2017 00:44:18 -0500, Andrew Z wrote:

> Hello,
>  i wonder how do i get the "for" and "if" to work against a dictionary
>  in
> one line?
> 
> basically i want to "squeeze":
>  dct= [ 1 : "one", 2:"two", 3:"three"]
>  for k, val in dct:
>if k >= 2:
>   # do magnificent things
> 
> Thank you AZ

why the need to single line it?
is your computer running out of new line & space characters?
it probably could be done with a dictionary comprehension but will that 
make things easier or harder to read/understand?

"Readability counts"




-- 
(Presuming for the sake of argument that it's even *possible* to design
better code in Perl than in C.  :-)
-- Larry Wall on core code vs. module code design
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32015] Asyncio looping during simultaneously socket read/write and reconnection

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset cc0961c517c31578f6a40a4dc7ea177d62c256b7 by Andrew Svetlov in 
branch '3.6':
[3.6] bpo-32015: Asyncio looping during simultaneously socket read/write an… 
(GH-4386) (#4393)
https://github.com/python/cpython/commit/cc0961c517c31578f6a40a4dc7ea177d62c256b7


--

___
Python tracker 

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

Re: from xx import yy (Posting On Python-List Prohibited)

[Lawrence D’Oliveiro]

On Monday, November 13, 2017 at 3:18:04 PM UTC+13, bvdp wrote:
> I'm having a conceptual mind-fart today. I just modified a bunch
> of code to use "from xx import variable" when variable is a global
> in xx.py. But, when I change/read 'variable' it doesn't appear to change.

1) Every name in Python is a variable.
2) Every distinct name (including qualifications) is a distinct variable. 
Changing one does not automatically change another. “from xx import yy” creates 
a variable named “yy” in the current scope, initialized to xx.yy but otherwise 
distinct from it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for/ if against dict - one liner

[Vincent Vande Vyvre]

Le 14/11/17 à 06:44, Andrew Z a écrit :

Hello,
  i wonder how do i get the "for" and "if" to work against a dictionary in
one line?

basically i want to "squeeze":
  dct= [ 1 : "one", 2:"two", 3:"three"]
  for k, val in dct:
if k >= 2:
   # do magnificent things

Thank you
AZ


Maybe something like that:

lst = [do_magnificent_thing(dct[k]) for k in dct if k >= 2]

lst contains the returns of do_magnificent_thing(k) in unpredictable order.


Vincent

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

Re: for/ if against dict - one liner

[Thomas Jollans]

On 2017-11-14 07:29, Stefan Ram wrote:
> Andrew Z  writes:
>> i wonder how do i get the "for" and "if" to work against a dictionary in
>> one line?
> 
> dict ={ 1 : "one", 2 : "two", 3 : "three" }
> print( *( ( str( key )+ ' ' + str( dict[ key ])) for key in dict if key >= 2 
> ), sep='\n' )
> 
>   prints:
> 
> 2 two
> 3 three
> 

We can build something nicer than that, surely. The repeated str() calls
and dictionary lookups just look like noise to my eyes.

print('\n'.join(f'{k} {v}' for k, v in dict.items() if k >= 2))

But indeed, you can build concise dictionary filters like that with
generator expressions and list comprehensions.


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

[issue32021] Brotli encoding is not recognized by mimetypes

[Andrey]

Andrey  added the comment:

Yes, however would it make sense to add it, so mimetypes recognizes it by 
default? I will make a PR if it makes sense.

--

___
Python tracker 

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

[issue32015] Asyncio looping during simultaneously socket read/write and reconnection

[Andrew Svetlov]

Change by Andrew Svetlov :


--
pull_requests: +4341

___
Python tracker 

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

[issue16055] incorrect error text for int(base=1000, x='1')

[STINNER Victor]

STINNER Victor  added the comment:

Thank you Sanyam Khurana, I merged your PR and backported the fix 
automaticalled to Python 3.6. Can you please try to backport the fix to Python 
2.7 and create a new PR?

--

___
Python tracker 

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