[issue21914] Create unit tests for Turtle guionly

2019-02-11 Thread RAJALAKSHMI V

RAJALAKSHMI V  added the comment:

I’m no longer working on this. Please feel free to take it up.

Rajalakshmi.V

> On 12-Feb-2019, at 11:48 AM, Joannah Nanjekye  wrote:
> 
> 
> Joannah Nanjekye  added the comment:
> 
> @RAJALAKSHMI V Any status on this? I would love to take this up if you are no 
> longer working on it.
> 
> --
> nosy: +nanjekyejoannah
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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



[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

2019-02-11 Thread Joannah Nanjekye


Joannah Nanjekye  added the comment:

What is the status on this? From this discussion, it looks like @vstinner 
pushed changes to resolve this. Do we close this? If this still needs a patch, 
then one of the patches can be reviewed in a PR on GitHub.

--
nosy: +nanjekyejoannah

___
Python tracker 

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



[issue21914] Create unit tests for Turtle guionly

2019-02-11 Thread Joannah Nanjekye


Joannah Nanjekye  added the comment:

@RAJALAKSHMI V Any status on this? I would love to take this up if you are no 
longer working on it.

--
nosy: +nanjekyejoannah

___
Python tracker 

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



comp.lang.python

2019-02-11 Thread Jaya Priya
The comp.lang.python.announce newsgroup (or c.l.py.a for short) has been 
created in early 1998 as a companion newsgroup for comp.lang.python focused on 
Python-related announcements. ... other items of general interest to the Python 
community.
https://www.gangboard.com/big-data-training/data-science-training
-- 
https://mail.python.org/mailman/listinfo/python-list


[issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed.

2019-02-11 Thread Guido van Rossum


Guido van Rossum  added the comment:

Thanks for the report!

I think I see a path through the code that doesn't free the memory.

Does this patch fix it?

diff --git a/Parser/parsetok.c b/Parser/parsetok.c
index 1fa4a1286b..6a96f6bc5a 100644
--- a/Parser/parsetok.c
+++ b/Parser/parsetok.c
@@ -370,7 +370,6 @@ parsetok(struct tok_state *tok, grammar *g, int start, 
perrdetail *err_ret,
 type_ignores.items[i], 0);
 }
 }
-growable_int_array_deallocate(_ignores);
 
 #ifndef PGEN
 /* Check that the source for a single input statement really
@@ -405,6 +404,8 @@ parsetok(struct tok_state *tok, grammar *g, int start, 
perrdetail *err_ret,
 else
 n = NULL;
 
+growable_int_array_deallocate(_ignores);
+
 #ifdef PY_PARSER_REQUIRES_FUTURE_KEYWORD
 *flags = ps->p_flags;
 #endif

--

___
Python tracker 

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



[issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed.

2019-02-11 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +gvanrossum

___
Python tracker 

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



[issue35934] Add socket.bind_socket() utility function

2019-02-11 Thread Giampaolo Rodola'


Giampaolo Rodola'  added the comment:

Closing this out as duplicate. Will continue in issue35934.

--
resolution:  -> duplicate
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



[issue17561] Add socket.bind_socket() convenience function

2019-02-11 Thread Giampaolo Rodola'


Giampaolo Rodola'  added the comment:

After iterating over this over the last few days I realized it makes more sense 
to implement and discuss the whole thing in here and as a single PR, so sorry 
about previously splitting this in a separate ticket/PR. Relevant PR is now 
this one and is ready for review:
https://github.com/python/cpython/pull/11784
Relevant changes which probably require attention/discussion are: 

1) since it was sort of ambiguous I renamed "has_dual_stack()" to 
"supports_hybrid_ipv46()". There could be space for some bikeshed as we already 
have "socket.has_ipv6" so this may be "has_hybrid_ipv46()" called instead

2) if family is unspecified and determined from *host* (e.g. "localhost" or "") 
the function sorts getaddrinfo() results preferring AF_INET over AF_INET6

3) doc includes link to my http://code.activestate.com/recipes/578504 recipe 
for platforms not supporting hybrid_ipv46 natively

4) it may be worthwhile (or maybe not?) to have another complementary 
bind_sockets() (plural) function returning all items from getaddrinfo(). That 
would be useful for non-blocking apps/frameworks and could be reused by asyncio.

Also, I'm CC-ing people from issue20215 as it contains relevant comments.

--
keywords:  -easy
nosy: +Carlos.Ralli, Paul Marks, andreasr, berker.peksag, dazhaoyu, 
gregory.p.smith, jleedev, jpokorny, martin.panter, nirs, r.david.murray
pull_requests: +11856
title: Add socket.create_server_sock() convenience function -> Add 
socket.bind_socket() convenience function

___
Python tracker 

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



[issue35976] PCBuild file changes for arm32 should be separated from code changes for review

2019-02-11 Thread Paul Monson


Change by Paul Monson :


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

___
Python tracker 

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



[issue35976] PCBuild file changes for arm32 should be separated from code changes for review

2019-02-11 Thread Paul Monson


Change by Paul Monson :


--
components: Build, Windows
nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: PCBuild file changes for arm32 should be separated from code changes for 
review
type: enhancement
versions: Python 3.8

___
Python tracker 

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



[issue35813] shared memory construct to avoid need for serialization between processes

2019-02-11 Thread Davin Potts


Davin Potts  added the comment:

@giampaolo.rodola: It definitely helps.


Conceptually, SyncManager provides "distributed shared memory" where lists, 
dicts, etc. are held in memory by one process but may be accessed remotely from 
another via a Proxy Object.  Mutating a dict from one process requires sending 
a message to some other process to request the change be made.

In contrast, SharedMemoryManager provides non-distributed shared memory where a 
special region of memory is held by the OS kernel (not a process) and made 
directly addressable to many processes simultaneously.  Modifying any data in 
this special region of memory requires zero process-to-process communication; 
any of the processes may modify the data directly.

In a speed contest, the SharedMemoryManager wins in every use case -- and it is 
not a close race.  There are other advantages and disadvantages to each, but 
speed is the key differentiator.


Thinking ahead to the future of SharedMemoryManager, there is the potential for 
a POSIX shared memory based semaphore.  The performance of this semaphore 
across processes should drastically outperform SyncManager's semaphore.  It 
might be something we will want to support in the future.  SharedMemoryManager 
needs a synchronization mechanism now (in support of common use cases) to 
coordinate across processes, which is why I initially thought 
SharedMemoryManager should expose the Lock, Semaphore, Event, Barrier, etc. 
powered by distributed shared memory.  I am no longer sure this is the right 
choice for three reasons:
(1) it unnecessarily complicates and confuses the separation of what is powered 
by fast SystemV-style shared memory and what is powered by slow distributed 
shared memory,
(2) it would be a very simple example in the docs to show how to add our 
existing Lock or Semaphore to SharedMemoryManager via register(),
(3) if we one day implement POSIX shared memory semaphores (and equivalent 
where POSIX is not supported), we will have the burden of an existing 
lock/semaphore creation methods and apis with behavioral differences.


I propose that it would be clearer but no less usable if we drop these 
registered object types (created via calls to register()) from 
SharedMemoryManager.  It is one line of code for a user to add "Lock" to 
SharedMemoryManager, which I think we can demonstrate well with a simple 
example.

--

___
Python tracker 

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



[issue35971] Documentation should warn about code injection from current working directory

2019-02-11 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

The change in behavior of Perl was discussed in 
https://mail.python.org/pipermail/python-ideas/2017-June/045842.html

--
nosy: +vstinner, xtreak

___
Python tracker 

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



Re: exit 2 levels of if/else and execute common code

2019-02-11 Thread Cameron Simpson

On 11Feb2019 08:17, Irv Kalb  wrote:

On Feb 11, 2019, at 7:25 AM, Neal Becker  wrote:
I have code with structure:
```
if cond1:
 [some code]
 if cond2: #where cond2 depends on the above [some code]
   [ more code]

 else:
   [ do xxyy ]
else:
 [ do the same xxyy as above ]
```

So what's the best style to handle this?  As coded, it violates DRY.
Try/except could be used with a custom exception, but that seems a bit heavy
handed.  Suggestions?



I like the additional function approach others have mentioned.  But if you want 
a different approach, you could do this:

runExtraCode = True# set some Boolean
if cond1:
   [some code]
   if cond2:
   [more code]
   runExtraCode = False  # both conditions met, no need to run the extra 
code

if runExtraCode:
   [do xxyy]


I want to second this. As others have said, there's a trivialness 
threshold where you wouldn't bother, and that is subjective. But when 
you do, the above is often useful. If "runExtraCode" bothers you, 
consider "need_task", with a suitable "task" name.


I've got several things in the above form. The most recent I fiddled 
with was last night, in a monitor script which updates some information.  
It takes the form:


 updated = False
 while True:
   time.sleep(INTERSCAN_DELAY)
   for rpath, dirnames, filenames in os.walk(...):
 ...
 for filename in filenames:
   if new file found:
 scan file ...
 updated = true
 if updated:
   update top level record ...
   updated = False
 ...

which updates a state file on a per subdirectory frequency if something 
new is found. This falls into exactly the pattern Irv describes.


You'll notice my example starts with the flag variable being False, and 
makes it True if the extra code should run. I personally prefer that 
pattern (I like things to generally start False, or zero, or empty), but 
what values you use will depend on what you're doing.


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


[issue35813] shared memory construct to avoid need for serialization between processes

2019-02-11 Thread Raymond Hettinger


Raymond Hettinger  added the comment:

FWIW, I read the draft docs and found them to be at the right level throughout. 
I definitely wouldn't want anything more terse.

--

___
Python tracker 

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



[issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms

2019-02-11 Thread Eric Snow


Eric Snow  added the comment:

Is "long long" (AKA int64_t) 32 bits or 64 bits on a 32-bit platform?  It it's 
always 32 bits then there is no problem here.  Otherwise I agree we have a 
problem to fix.  My understanding is that it is the former (always 32 bits).

--

___
Python tracker 

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



[issue35975] Put back the ability to parse files where async/await aren't keywords

2019-02-11 Thread Ethan Smith


Change by Ethan Smith :


--
nosy: +Ethan Smith

___
Python tracker 

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



[issue35918] multiprocessing's SyncManager.dict.has_key() method is broken

2019-02-11 Thread Giampaolo Rodola'


Giampaolo Rodola'  added the comment:


New changeset 58f05ce059cc5207320fef27a9fbc0ffdc2b1d1a by Giampaolo Rodola 
(Miss Islington (bot)) in branch '3.7':
bpo-35918: Remove broken has_key method and add test (GH-11819) (#11824)
https://github.com/python/cpython/commit/58f05ce059cc5207320fef27a9fbc0ffdc2b1d1a


--

___
Python tracker 

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



[issue35918] multiprocessing's SyncManager.dict.has_key() method is broken

2019-02-11 Thread miss-islington


Change by miss-islington :


--
pull_requests: +11854

___
Python tracker 

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



[issue35918] multiprocessing's SyncManager.dict.has_key() method is broken

2019-02-11 Thread Giampaolo Rodola'

Giampaolo Rodola'  added the comment:


New changeset a31f4cc881992e84d351957bd9ac1a92f882fa39 by Giampaolo Rodola 
(Rémi Lapeyre) in branch 'master':
bpo-35918: Remove broken has_key method and add test (#11819)
https://github.com/python/cpython/commit/a31f4cc881992e84d351957bd9ac1a92f882fa39


--

___
Python tracker 

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



[issue35975] Put back the ability to parse files where async/await aren't keywords

2019-02-11 Thread Ivan Levkivskyi


Change by Ivan Levkivskyi :


--
nosy: +levkivskyi

___
Python tracker 

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



[issue35505] Test test_imaplib fail in test_imap4_host_default_value

2019-02-11 Thread Matej Cepl


Change by Matej Cepl :


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

___
Python tracker 

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



[issue35963] Python/symtable.c: warning: enumeration value ‘FunctionType_kind’ not handled in switch [-Wswitch]"

2019-02-11 Thread Guido van Rossum


Change by Guido van Rossum :


--
stage:  -> resolved

___
Python tracker 

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



[issue35766] Merge typed_ast back into CPython

2019-02-11 Thread Guido van Rossum


Guido van Rossum  added the comment:

See https://bugs.python.org/issue35975

--

___
Python tracker 

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



[issue35975] Put back the ability to parse files where async/await aren't keywords

2019-02-11 Thread Guido van Rossum

New submission from Guido van Rossum :

Now that the ast module can be used to parse type comments, there’s one more 
feature I’d like to lobby for – a flag that modifies the grammar slightly so it 
resembles an older version of Python (going back to 3.4).

This is used in mypy to decouple the Python version you’re running from the 
Python version for which you’re checking compatibility (useful when checking 
code that will be deployed on a system with a different Python version 
installed). I imagine this would be useful to other linters as well, and the 
implementation is mostly manipulating whether `async` and `await` are keywords. 
But if there’s pushback to this part I can live without it – the rest of the 
work is still useful.

The implementation in typed_ast takes the form of a feature_version flag which 
is set to the minor Python version to be parsed. Setting it to 4 or lower would 
make async/await never keywords, setting it to 5 or 6 would make them 
conditional per PEP 492, and setting it to 7 or higher would make these 
unconditional keywords. A few minor uses of the same flag also reject 
f-strings, annotated assignments (PEP 526), and matrix multiply for versions 
where those don't exist.

But I don't need all of those -- I really just need to be able to select the 
3.5/3.6 rules for conditional async/await keywords, since all the other 
features are purely backwards compatible, whereas with async/await there is 
legal (and plentiful!) code that uses these as variable or function names that 
should be supported in 3.5/3.6 mode.

Of course having it be a (minor) version number would still be more 
future-proof -- if say in 3.10 we add a match expression using some kind of 
conditional keyword hack, we might have to dust it off.

Note that much of what I'm asking for would effectively roll back 
https://bugs.python.org/issue30406 -- sorry Jelle! (Though there's more to it 
-- Serhiy's introduction of Grammar/Token followed, and I would still need to 
thread some kind of flag all the way from ast.parse() to tokenizer.c.

--
messages: 335277
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Put back the ability to parse files where async/await aren't keywords

___
Python tracker 

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



[issue35766] Merge typed_ast back into CPython

2019-02-11 Thread Guido van Rossum


Guido van Rossum  added the comment:

I have some follow-up wishes but I'll create a new issue.

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



[issue35963] Python/symtable.c: warning: enumeration value ‘FunctionType_kind’ not handled in switch [-Wswitch]"

2019-02-11 Thread Guido van Rossum


Change by Guido van Rossum :


--
stage: resolved -> 

___
Python tracker 

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



[issue35974] os.DirEntry.inode() returns invalid value within Docker container

2019-02-11 Thread Marat Sharafutdinov


New submission from Marat Sharafutdinov :

I'm trying to build Python 3.7.2 within official CentOS 7.6.1810 image 
(https://hub.docker.com/_/centos) and getting the following error during 
testing:

==
FAIL: test_attributes (test.test_os.TestScandir)
--
Traceback (most recent call last):
  File "/usr/src/python/Lib/test/test_os.py", line 3367, in test_attributes
self.check_entry(entry, 'dir', True, False, False)
  File "/usr/src/python/Lib/test/test_os.py", line 3319, in check_entry
os.stat(entry.path, follow_symlinks=False).st_ino)
AssertionError: 28093768 != 85098458

I guess this bug applies to Docker containers in general. For instance it's 
reproduced with the official Python 3.7.2-stretch image based on the Debian 
Stretch (https://hub.docker.com/_/python):

$ docker run --rm -it python:3.7.2-stretch
Python 3.7.2 (default, Feb  6 2019, 12:04:03) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.mkdir('/test_dir')
>>> for entry in os.scandir('/'):
...   if entry.name == 'test_dir':
... break
... 
>>> print(entry, entry.inode(), os.stat(entry.path, 
>>> follow_symlinks=False).st_ino)
 23898155 85118011
>>> assert entry.inode() == os.stat(entry.path, follow_symlinks=False).st_ino
Traceback (most recent call last):
  File "", line 1, in 
AssertionError
>>> 

In case of using host volume when running container it works ok, - the problem 
occurs when using default Docker volume:

$ docker run --rm -it -v /home/decaz/workspace:/host_dir python:3.7.2-stretch
Python 3.7.2 (default, Feb  6 2019, 12:04:03) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.mkdir('/host_dir/test_dir')
>>> for entry in os.scandir('/host_dir'):
...   if entry.name == 'test_dir':
... break
... 
>>> print(entry, entry.inode(), os.stat(entry.path, 
>>> follow_symlinks=False).st_ino)
 12873222 12873222
>>> assert entry.inode() == os.stat(entry.path, follow_symlinks=False).st_ino
>>> 

Similar issue - https://bugs.python.org/issue32811.

--
components: Build
messages: 335275
nosy: decaz
priority: normal
severity: normal
status: open
title: os.DirEntry.inode() returns invalid value within Docker container
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



[issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed.

2019-02-11 Thread Brennan Vincent


New submission from Brennan Vincent :

To reproduce:

(1) build python: `../configure --prefix=$HOME/prefix --with-pydebug 
--without-pymalloc && make install`

(2) run with valgrind: `valgrind --leak-check=full ~/prefix/bin/python3`

(3) exit immediately from the interpreter by pressing ^D

(4) Note the following output from Valgrind:

```
==3810071== 40 bytes in 1 blocks are definitely lost in loss record 3 of 527
==3810071==at 0x4C28B5F: malloc (vg_replace_malloc.c:299)
==3810071==by 0x59ED58: growable_int_array_init (parsetok.c:27)
==3810071==by 0x59EE14: parsetok (parsetok.c:235)
==3810071==by 0x59F697: PyParser_ParseFileObject (parsetok.c:176)
==3810071==by 0x522E85: PyParser_ASTFromFileObject (pythonrun.c:1224)
==3810071==by 0x5231E9: PyRun_InteractiveOneObjectEx (pythonrun.c:238)
==3810071==by 0x5234D0: PyRun_InteractiveLoopFlags (pythonrun.c:120)
==3810071==by 0x523BF2: PyRun_AnyFileExFlags (pythonrun.c:78)
==3810071==by 0x4204FE: pymain_run_stdin (main.c:1185)
==3810071==by 0x42126B: pymain_run_python (main.c:1675)
==3810071==by 0x422EE0: pymain_main (main.c:1820)
==3810071==by 0x422F75: _Py_UnixMain (main.c:1857)
```

Reproduced on git commit hash 522346d792d9013140a3f4ad3534ac10f38d9085 .

--
components: Interpreter Core
messages: 335274
nosy: umanwizard
priority: normal
severity: normal
status: open
title: `growable_int_array type_ignores` in parsetok.c is not always freed.
type: resource usage
versions: Python 3.8

___
Python tracker 

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



[issue35813] shared memory construct to avoid need for serialization between processes

2019-02-11 Thread Giampaolo Rodola'


Giampaolo Rodola'  added the comment:

I submitted an initial review / comments in the PR. I think this is good for a 
first iteration in order to understand what APIs to expose publicly (also, keep 
in mind I may not have a full picture of how this is intended to be used 
precisely).

As for the doc, I find it a bit too verbose. If the namespace change is 
accepted consider doing the following:

* document `SharedMemoryManager` right after `SyncManager`. That would let you 
reuse the description for `Semaphore`, `Barrier`, `Lock`, etc.
* within `SharedMemoryManager` doc link/point to a different section of the doc 
where you explain the whole thing in more details, and also document the 
remaining APIs 

Just an idea. Writing good doc is not easy and it requires actually putting 
hands on it. 

Hope this helps.

--

___
Python tracker 

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



Re: Replicating YouTube video AI code in python

2019-02-11 Thread jadenfigger
The error I get typing  pip install -U  tensorflow into the command terminal
  Could not find a version that satisfies the requirement tensorflow (from 
versions: )
No matching distribution found for tensorflow.

Ive been able to install numpy, scipy, and pygame. Tensorflow is the only 
package that gives this error.

I've tried using python 3.7 and 3.6
-- 
https://mail.python.org/mailman/listinfo/python-list


[issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms

2019-02-11 Thread Alexey Izbyshev


Change by Alexey Izbyshev :


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

___
Python tracker 

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



[issue35972] _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms

2019-02-11 Thread Alexey Izbyshev


New submission from Alexey Izbyshev :

Victor Stinner pointed out that on x86 Gentoo Installed with X 3.x buildbot, 
there is a compiler warning:

Python/pystate.c:1483:18: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]

(https://buildbot.python.org/all/#/builders/103/builds/2067)

This warning reveals a bug:

static int
_long_shared(PyObject *obj, _PyCrossInterpreterData *data)
{
int64_t value = PyLong_AsLongLong(obj);
if (value == -1 && PyErr_Occurred()) {
if (PyErr_ExceptionMatches(PyExc_OverflowError)) {
PyErr_SetString(PyExc_OverflowError, "try sending as bytes");
}
return -1;
}
data->data = (void *)value;

A 64-bit value is converted to void *, which is 32-bit on 32-bit platforms.

I've implemented a PR that uses Py_ssize_t instead to match the pointer size 
and to preserve the ability to work with negative numbers.

--
assignee: izbyshev
components: Extension Modules
messages: 335272
nosy: eric.snow, izbyshev, vstinner
priority: normal
severity: normal
status: open
title: _xxsubinterpreters: channel_send() may truncate ints on 32-bit platforms
type: behavior
versions: Python 3.8

___
Python tracker 

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



[issue35971] Documentation should warn about code injection from current working directory

2019-02-11 Thread Gabriel Corona


New submission from Gabriel Corona :

The CLI tools shipped in Debian python-rdflib-tools package can load modules 
from the current directory [1]:

$ echo 'print("Something")' > cgi.py
$ rdf2dot
INFO:rdflib:RDFLib Version: 4.2.2
Something
Reading from stdin as None...

This could be a security issue because an attacker could possibly exploit this 
behavior to execute arbitrary code.

This happens because these CLI tools are implemented as:

#!/bin/sh

exec /usr/bin/python -m rdflib.tools.rdfpipe $*

"python -m $module", "python -c $code" and "$command | python" prepend the 
current working directory in the Python path. The Python documentation [2] 
should probably warn about this. In Python 3, "-I" could be suggested to 
prevent the script/current directory to be added to the Python path. However, 
this flag has other effects.

The Python documentation suggests "python -m" commands at some places [3-5]: 
some form of warning at those places might be nice as well.

See the related behavior of Perl. Perl used to include "." in @INC but this was 
removed for security reasons [6].


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921751.
[2] https://docs.python.org/3/using/cmdline.html
[3] https://docs.python.org/3.1/library/json.html
[4] https://docs.python.org/3/library/http.server.html
[5] https://docs.python.org/3/library/zipapp.html
[6] 
https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/perldelta.pod#Removal-of-the-current-directory-%28%22.%22%29-from-@INC

--
messages: 335271
nosy: Gabriel Corona
priority: normal
severity: normal
status: open
title: Documentation should warn about code injection from current working 
directory
type: security
versions: Python 2.7, Python 3.4, 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



[issue2771] Test issue

2019-02-11 Thread Stéphane Wirtel

Stéphane Wirtel  added the comment:

irc pong

--
nosy: +matrixise

___
Python tracker 

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



Re: The slash "/" as used in the documentation

2019-02-11 Thread Chris Angelico
On Tue, Feb 12, 2019 at 8:13 AM Avi Gross  wrote:
>
>
> Just Chris,

Can we keep things on the list please?

> I am thinking I missed the point of this discussion thus what I say makes no
> sense.

Not sure. You were fairly specific with your statements about how
things supposedly were in the past. What point of the discussion did
you miss that led you to say that?

> Yes, the equals is THE way you supply defaults for things you optionally
> want the user to be able to override. I seem to be talking top-level python
> and you guys are elsewhere so I must be in another discussion.
>
> On Tue, Feb 12, 2019 at 7:26 AM Avi Gross  wrote:
> > If you want to talk about recent or planned changes, fine. But make
> > that clear. I was talking about how in the past positional arguments
> > did not have defaults available at the def statement level. I was
> > talking about how use of the symbol "=" in the context of defining
> > function parameters had multiple meanings. It not only established
> > that the parameter accepted a keyword but also provided a default.

You state this as fact. That's what I responded to. What do you mean
by "top level Python" that might make your statement true?

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


Re: more pythonic way

2019-02-11 Thread Jimmy Girardet
The first one is used very often. Less verbose

Le 11 févr. 2019 à 20:41, à 20:41, Felix Lazaro Carbonell 
 a écrit:
> 
>
>Hello to everyone:
>
>Could you please tell me wich way of writing this method is more
>pythonic:
>
> 
>
>..
>
>def find_monthly_expenses(month=None, year=None):
>
>month = month or datetime.date.today()
>
>..
>
> 
>
>Or it should better be:
>
>...
>
>if not month:
>
>month = datetime.date.today()
>
>..
>
> 
>
>Cheers,
>
>Felix.
>
> 
>
>-- 
>https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Can't run setup.py offline due to setup_requires - setup.py calls home

2019-02-11 Thread Chris Narkiewicz via Python-list
On 11/02/2019 19:30, Chris Narkiewicz via Python-list wrote:
> Is there any extra step I have to take?

Ok, I'll respond to myself, as this was really silly.
Debian ships hopelessly obsolete pip 9.PEP 518 is supported in pip 10+.

Cheers,
Chris



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


Re: The slash "/" as used in the documentation

2019-02-11 Thread Ian Kelly
On Mon, Feb 11, 2019 at 1:56 PM boB Stepp  wrote:
>
> On Mon, Feb 11, 2019 at 2:34 PM Chris Angelico  wrote:
>
> > Calling on the D'Aprano Collection of Ancient Pythons for confirmation
> > here, but I strongly suspect that positional arguments with defaults
> > go back all the way to 1.x.
>
> Has Steve's banishment ended yet?  The only postings I have recently
> seen from him have been on the Tutor list.

It should have ended some time in December. Perhaps he's decided not to return.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: more pythonic way

2019-02-11 Thread Peter Otten
Felix Lazaro Carbonell wrote:

> Hello to everyone:

 
> Could you please tell me wich way of writing this method is more pythonic:
> def find_monthly_expenses(month=None, year=None):
> 
> month = month or datetime.date.today()

> Or it should better be:

> if not month:
> month = datetime.date.today()

Personally I would avoid a default because I'm unsure whether the current or 
the previous month is the right default. 

Also, the default month combined with a specific year doesn't make much 
sense to me, and someone who specifies find_monthly_expenses(month=6) in May 
probably wants the June of the past year...

Keep the function simple an make the arguments non-optional. If you can come 
up with a nice heuristic put it in a separate function.

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


Re: The slash "/" as used in the documentation

2019-02-11 Thread boB Stepp
On Mon, Feb 11, 2019 at 2:34 PM Chris Angelico  wrote:

> Calling on the D'Aprano Collection of Ancient Pythons for confirmation
> here, but I strongly suspect that positional arguments with defaults
> go back all the way to 1.x.

Has Steve's banishment ended yet?  The only postings I have recently
seen from him have been on the Tutor list.



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


Re: The slash "/" as used in the documentation

2019-02-11 Thread Ian Kelly
On Mon, Feb 11, 2019 at 1:35 PM Chris Angelico  wrote:
>
> On Tue, Feb 12, 2019 at 7:26 AM Avi Gross  wrote:
> > If you want to talk about recent or planned changes, fine. But make that
> > clear. I was talking about how in the past positional arguments did not have
> > defaults available at the def statement level. I was talking about how use
> > of the symbol "=" in the context of defining function parameters had
> > multiple meanings. It not only established that the parameter accepted a
> > keyword but also provided a default.
>
> When was this the case? Positional arguments with defaults is a
> concept known in MANY languages, including C. The equals sign has
> nothing to do with keyword arguments.
>
> Calling on the D'Aprano Collection of Ancient Pythons for confirmation
> here, but I strongly suspect that positional arguments with defaults
> go back all the way to 1.x.

The archived documentation shows that both parameter defaults and
keyword arguments have been around since at least 1.4. I can't
directly confirm that required parameters could be passed by keyword,
but I see nothing in there that says they can't, or that appears to
conflate parameters having defaults with keyword arguments, which is
as one would expect -- whether an argument is passed positionally or
by keyword is a property of the function *call* expression, whereas
whether a parameter has a default or not is a property of the function
*definition*. They happen to both use the = symbol followed by an
expression, but in different syntactical environments, and that is the
only correlation between them.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: more pythonic way

2019-02-11 Thread Peter Otten
Grant Edwards wrote:

> On 2019-02-11, Felix Lazaro Carbonell  wrote:
> 
>> Could you please tell me wich way of writing this method is more
>> pythonic:
>>
>> def find_monthly_expenses(month=None, year=None):
>> month = month or datetime.date.today()
>>
>> Or it should better be:
>>
>> if not month:
>> month = datetime.date.today()
> 
> The most pythonic way is to do this:
> 
>def find_monthly_expenses(month=datetime.date.today().month,
>year=datetime.date.today().year):
>   ...
> 
> And then start a month-long argument on the mailing list about how the
> behavior of parameter default values is wrong and needs be changed.
> 
> ;)
> 

As far as arguments go I was thinking more about how this code can try and 
find the december expenses when it's only january ;)

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


Re: more pythonic way

2019-02-11 Thread Sivan Grünberg
+1 with David Raymond, it's nice to use condensed style when it leaves
things readable and logic. But if in doubt:
"Explicit is better than implicit.
Simple is better than complex."  :)

-Sivan

On Mon, Feb 11, 2019 at 10:19 PM David Raymond 
wrote:

> My non-expert vote is for
>
> if month is None:
> month = datetime.date.today().month
>
> Because you're checking for your default value, not whether the boolean
> version of what they did give you is True or False. It's explicit, it's not
> reliant on any __bool__() function implementations or overrides, etc.
>
>
> -Original Message-
> From: Python-list [mailto:python-list-bounces+david.raymond=
> tomtom@python.org] On Behalf Of Felix Lazaro Carbonell
> Sent: Monday, February 11, 2019 2:30 PM
> To: python-list@python.org
> Subject: more pythonic way
>
>
>
> Hello to everyone:
>
> Could you please tell me wich way of writing this method is more pythonic:
>
>
>
> ..
>
> def find_monthly_expenses(month=None, year=None):
>
> month = month or datetime.date.today()
>
> ..
>
>
>
> Or it should better be:
>
> ...
>
> if not month:
>
> month = datetime.date.today()
>
> ..
>
>
>
> Cheers,
>
> Felix.
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Sivan Greenberg
Co founder & CTO
Vitakka Consulting
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: more pythonic way

2019-02-11 Thread Terry Reedy

On 2/11/2019 2:46 PM, Felix Lazaro Carbonell wrote:


 def find_monthly_expenses(month=None, year=None):
 month = month or datetime.date.today().month

Or it should better be:



 if not month:
 month = datetime.date.today().month


As a 20+ year veteran, I would be fine either way.

--
Terry Jan Reedy

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


Re: The slash "/" as used in the documentation

2019-02-11 Thread Chris Angelico
On Tue, Feb 12, 2019 at 7:26 AM Avi Gross  wrote:
> If you want to talk about recent or planned changes, fine. But make that
> clear. I was talking about how in the past positional arguments did not have
> defaults available at the def statement level. I was talking about how use
> of the symbol "=" in the context of defining function parameters had
> multiple meanings. It not only established that the parameter accepted a
> keyword but also provided a default.

When was this the case? Positional arguments with defaults is a
concept known in MANY languages, including C. The equals sign has
nothing to do with keyword arguments.

Calling on the D'Aprano Collection of Ancient Pythons for confirmation
here, but I strongly suspect that positional arguments with defaults
go back all the way to 1.x.

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


RE: The slash "/" as used in the documentation

2019-02-11 Thread Avi Gross
Ian,

Again, not having read whatever documentation we may be discussing, I may be
very wrong.

The topic is the C API. I started using C at Bell Laboratories in 1982
replacing other languages I had used before. I haven't felt a reason to use
it in the last few decades as I moved on to yet other languages but am quite
aware that many of those languages are largely interpreters written in
languages like C or C++ and then regularly patched by adding C-like code to
replace slower functionality. I assume the C API you are mentioning refers
to the process of how you write and compile and invoke library functions so
that the function called will properly place python data structures in some
kind of stack so that the C library can properly take it and perform
computations. Similarly, when the function returns, some additional mapping
may be done. The above is meant to be general and obviously the details
matter.

C as a stand-alone language used to have pretty much positional arguments
and often a fixed number of them. We often had multiple functions we could
call with slightly different names if we wanted special effects like not
requiring a third argument. Clearly some approaches were less efficient if
the two-argument version simply turned around and called the three-argument
version with a third argument set to a default. So, often you played other
games like requiring a third argument (or in some languages a dangling
comma) which the function might choose to replace with a default internally
if it is something like -1. Obviously C libraries that are external must be
used as-is while internal ones you have written might allow changes.

Some languages I have used do not so much support doing lots of command-line
level pre-processing of command-line arguments but provide helper functions
that can be called within the function call that take all the arguments and
do further processing and return a form that the function can more easily
use. This works even better when evaluation is lazy and you can access the
exact original text the programmer or user typed in before it is evaluated.
Python now allows a limited form of that if you ask for *args and **kwargs.

So is this mainly about efficiency and C libraries or more? You can easily
make a C function that expects positional arguments in a proper order and
then make a wrapper in python (or C or FORTRAN or whatever) with a slightly
different name that does preprocessing and/or postprocessing. Python is
loaded with such functionality that tends to allow more complex things to be
done less efficiently. So if the wrapper can evaluate your arguments and
figure out what to do with positional arguments, great. The wrapper function
might support an optional argument that specifies whether other argument
units are in feet, miles, meters or even parsecs and also accept keyword
arguments for those measures and rescale them and only then call the
efficient C function with all the right arguments in the right positions. If
you as a programmer find that slows things down, you can make sure you use
the right units for the function and call the underlying function directly
with everything in place according to those rules.

Ending with this. Is the reality that we are now talking about gradual
changes in documentation as individual C functions are updated but not at
this point about what normal python users are seeing in terms of the code?
If so, I repeat, I was not talking about that and my comments are not
applicable and I can go back to doing more useful things away from this
forum.

-Original Message-
From: Python-list  On
Behalf Of Ian Kelly
Sent: Monday, February 11, 2019 1:46 AM
To: Python 
Subject: Re: The slash "/" as used in the documentation

On Sun, Feb 10, 2019 at 2:18 PM Avi Gross  wrote:
> I am not sure how python implements some of the functionality it does 
> as compared to other languages with similar features. But I note that 
> there are rules, presumably some for efficiency, such as requiring all 
> keyword arguments to be placed after the last positional argument. I 
> mean I can call
> func(a,b,c,d=1,e=2) but not func(a,b,d=1, c, e=2).
>
> So if you allowed a keyword to optionally be used for any positional 
> argument other than the last, c, would it not require a change in this
rule?
> I mean func(a="invalid",b,c,d=1,e=2) would violate the rule and so 
> would making b a keyword version. In my example, and for this reason 
> only, maybe c could work.

My suggestion was not to allow keyword arguments to arbitrarily replace any
positional parameter, or to otherwise change argument-passing in any way.
The suggestion was to drop positional-only arguments from functions
implemented in C instead of just documenting them better. In the example
above, if you want to pass a by keyword, you would have to pass b and c by
keyword as well.
That would still be true for functions implemented in C if a, b, and c are
no longer positional-only.

> The original 

RE: The slash "/" as used in the documentation

2019-02-11 Thread Avi Gross
Ian,

I now assume we are no longer talking about the past or even the present but
some planned future. In that future we are talking about how to define a
function with added or changed functionality. So nothing I wrote earlier
really applies because I was talking of how things did work in the absence
of the changes needed to make new functionality possible.

So let me make sure I understood you. We are talking about the function
prototype as in def fun(...) and perhaps the lambda equivalent. The user of
the function would only see changes in the help files or other documentation
but no special symbols would be used when they invoke a function, albeit new
error messages may also happen if done wrong.

The earlier messages talked about using a forward slash but you seem to use
an asterisk for the same purpose. You can use the very overloaded "*"
character as a delimiter between the parameters mentioned to the left and
any remaining ones to the right. The "=" symbol is thus now allowed on
either side of the divide and now ONLY means there is a default. 

I thought the discussion was about python, not the C API that arguably is
used as much of python is in C directly or indirectly. I thought we were
talking about updating everything at the top interpreted python levels.
Please make it clear if we are not.

Will the above functionality, if understood, break (or modify how it works)
existing python code? I mean code that only uses the asterisk to denote
multiplication, exponentiation, list expansion and dictionary expansion and
so on. 

Just based on what you wrote, maybe not. It depends on the new meaning of
not having a sole asterisk somewhere in the parameter list. If that means
evaluate old style, great. If it means something else, I won't speculate but
can picture problems.

I will talk about your C API question in another message.


-Original Message-
From: Python-list  On
Behalf Of Ian Kelly
Sent: Monday, February 11, 2019 1:46 AM
To: Python 
Subject: Re: The slash "/" as used in the documentation

On Sun, Feb 10, 2019 at 2:18 PM Avi Gross  wrote:
> I am not sure how python implements some of the functionality it does 
> as compared to other languages with similar features. But I note that 
> there are rules, presumably some for efficiency, such as requiring all 
> keyword arguments to be placed after the last positional argument. I 
> mean I can call
> func(a,b,c,d=1,e=2) but not func(a,b,d=1, c, e=2).
>
> So if you allowed a keyword to optionally be used for any positional 
> argument other than the last, c, would it not require a change in this
rule?
> I mean func(a="invalid",b,c,d=1,e=2) would violate the rule and so 
> would making b a keyword version. In my example, and for this reason 
> only, maybe c could work.

My suggestion was not to allow keyword arguments to arbitrarily replace any
positional parameter, or to otherwise change argument-passing in any way.
The suggestion was to drop positional-only arguments from functions
implemented in C instead of just documenting them better. In the example
above, if you want to pass a by keyword, you would have to pass b and c by
keyword as well.
That would still be true for functions implemented in C if a, b, and c are
no longer positional-only.

> The original motivation for keyword arguments included the concept of 
> specifying a default if not used. Positional arguments have no default.
> Similarly, they are required if explicitly named in the function
definition.
> So we are intermingling multiple concepts in the previous design.

Positional arguments are allowed to have defaults, and keyword-only
arguments are allowed to not have defaults. These are all valid
syntax:

# Allows a and b to be passed either positionally or by keyword def foo(a=1,
b=2): pass

# b is keyword-only
def foo(a=1, *, b=2): pass

# Allows a and b to be passed either positionally or by keyword def foo(a,
b): pass

# b is keyword-only and has no default
def foo(a, *, b): pass

Positional-ONLY arguments are not directly supported by the language, but
they exist in the C API and can also have defaults. For example, dict.get
takes two positional-only arguments. The second argument is optional, and
its default is None.

My point is that the axis of positional-only versus positional-or-keyword
versus keyword-only, and the axis of required versus optional are entirely
separate.

> I won't go on except to say it would break lots of existing code and 
> potentially complicate new code.

Can you give an example of something that would be broken by updating C API
functions to name positional-only arguments instead of just updating them to
document that they're positional-only?
--
https://mail.python.org/mailman/listinfo/python-list

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


RE: The slash "/" as used in the documentation

2019-02-11 Thread Avi Gross
Ian,

I want to make sure we are talking about the same things in the same ways. I
will thus limit my comments in this message.

If efficiency is your major consideration, then using only positional
arguments of known types you can place on the stack and optimize at compile
time may be a great way to go. It is not the way python generally goes as it
supports objects at run time that can be of any type and in many cases
allows any number of arguments to a function.

Python was designed till recently in a way that valued some more innovative
methods and that included allowing a combination of positional and keyword
arguments. The positional arguments can still be called with keyword but
only if moved beyond any other positional arguments. What evolved is NOT the
only way I have seen this done. But what I see now is not what you are
describing in some ways.

If you want to talk about recent or planned changes, fine. But make that
clear. I was talking about how in the past positional arguments did not have
defaults available at the def statement level. I was talking about how use
of the symbol "=" in the context of defining function parameters had
multiple meanings. It not only established that the parameter accepted a
keyword but also provided a default. The allowed syntax required a default,
even if it was None. I mean the following fails:

>>> def func(a,b=): pass
SyntaxError: invalid syntax

If in the future (or some other language) you want to allow some way of
assigning a default to positional arguments, fine. What I see today does
not. 

So if I understand you, there is a proposal or even plan to change some of
the current functionality. I still have not seen anyone post a reference as
requested. I am very open to seeing what people are considering or maybe
even implementing and in what ways it may not be compatible with present
functionality.



-Original Message-
From: Python-list  On
Behalf Of Ian Kelly
Sent: Monday, February 11, 2019 1:46 AM
To: Python 
Subject: Re: The slash "/" as used in the documentation

On Sun, Feb 10, 2019 at 2:18 PM Avi Gross  wrote:
> I am not sure how python implements some of the functionality it does 
> as compared to other languages with similar features. But I note that 
> there are rules, presumably some for efficiency, such as requiring all 
> keyword arguments to be placed after the last positional argument. I 
> mean I can call
> func(a,b,c,d=1,e=2) but not func(a,b,d=1, c, e=2).
>
> So if you allowed a keyword to optionally be used for any positional 
> argument other than the last, c, would it not require a change in this
rule?
> I mean func(a="invalid",b,c,d=1,e=2) would violate the rule and so 
> would making b a keyword version. In my example, and for this reason 
> only, maybe c could work.

My suggestion was not to allow keyword arguments to arbitrarily replace any
positional parameter, or to otherwise change argument-passing in any way.
The suggestion was to drop positional-only arguments from functions
implemented in C instead of just documenting them better. In the example
above, if you want to pass a by keyword, you would have to pass b and c by
keyword as well.
That would still be true for functions implemented in C if a, b, and c are
no longer positional-only.

> The original motivation for keyword arguments included the concept of 
> specifying a default if not used. Positional arguments have no default.
> Similarly, they are required if explicitly named in the function
definition.
> So we are intermingling multiple concepts in the previous design.

Positional arguments are allowed to have defaults, and keyword-only
arguments are allowed to not have defaults. These are all valid
syntax:

# Allows a and b to be passed either positionally or by keyword def foo(a=1,
b=2): pass

# b is keyword-only
def foo(a=1, *, b=2): pass

# Allows a and b to be passed either positionally or by keyword def foo(a,
b): pass

# b is keyword-only and has no default
def foo(a, *, b): pass

Positional-ONLY arguments are not directly supported by the language, but
they exist in the C API and can also have defaults. For example, dict.get
takes two positional-only arguments. The second argument is optional, and
its default is None.

My point is that the axis of positional-only versus positional-or-keyword
versus keyword-only, and the axis of required versus optional are entirely
separate.

> I won't go on except to say it would break lots of existing code and 
> potentially complicate new code.

Can you give an example of something that would be broken by updating C API
functions to name positional-only arguments instead of just updating them to
document that they're positional-only?
--
https://mail.python.org/mailman/listinfo/python-list

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


RE: more pythonic way

2019-02-11 Thread David Raymond
My non-expert vote is for

if month is None:
month = datetime.date.today().month

Because you're checking for your default value, not whether the boolean version 
of what they did give you is True or False. It's explicit, it's not reliant on 
any __bool__() function implementations or overrides, etc.


-Original Message-
From: Python-list 
[mailto:python-list-bounces+david.raymond=tomtom@python.org] On Behalf Of 
Felix Lazaro Carbonell
Sent: Monday, February 11, 2019 2:30 PM
To: python-list@python.org
Subject: more pythonic way

 

Hello to everyone:

Could you please tell me wich way of writing this method is more pythonic:

 

..

def find_monthly_expenses(month=None, year=None):

month = month or datetime.date.today()

..

 

Or it should better be:

...

if not month:

month = datetime.date.today()

..

 

Cheers,

Felix.

 

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


[issue35955] difflib reports incorrect location of mismatch

2019-02-11 Thread Tim Peters


Tim Peters  added the comment:

It's probably OK, but there's no "pure win" to be had here.  There's generally 
more than one way to convert one string to another, and what "looks right" to 
humans depends a whole lot on context.

For example, consider these strings:

"private Thread currentThread;"
"private volatile Thread currentThread;"

"It's obvious" someone inserted "volatile" into the first string, and that's 
what ndiff's default says:

- private Thread currentThread;
+ private volatile Thread currentThread;
? +

However, pass `charjunk=None` instead, and ndiff claims someone inserted "e 
volatil" after the "t" in "private":

- private Thread currentThread;
+ private volatile Thread currentThread;
?   +

Which is also a correct way, but - to human eyes - an insane way ;-)

--

___
Python tracker 

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



[issue35955] difflib reports incorrect location of mismatch

2019-02-11 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

Nice insight Tim.

--

___
Python tracker 

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



RE: more pythonic way

2019-02-11 Thread Felix Lazaro Carbonell



-Mensaje original-
De: Python-list [mailto:python-list-bounces+felix=epepm.cupet...@python.org]
En nombre de Grant Edwards
Enviado el: lunes, 11 de febrero de 2019 02:46 p.m.
Para: python-list@python.org
Asunto: Re: more pythonic way

On 2019-02-11, Felix Lazaro Carbonell  wrote:

> Could you please tell me wich way of writing this method is more pythonic:
>
> def find_monthly_expenses(month=None, year=None):
> month = month or datetime.date.today()
>
> Or it should better be:
>
> if not month:
> month = datetime.date.today()

>The most pythonic way is to do this:
>
>   def find_monthly_expenses(month=datetime.date.today().month,
year=datetime.date.today().year):
>  ...
>
>And then start a month-long argument on the mailing list about how the
behavior of parameter default values is wrong and needs be changed.
>
>;)
>
>-- 
>Grant Edwards   grant.b.edwardsYow! I always have fun
>  at   because I'm out of my
>  gmail.commind!!!
>
>--

Thanks Grant:

 but now I think I should have mentioned that this is a method in a Django
model, and default arguments are evaluated once when the method is defined,
not each time the method is called.
So, your way, wil yield the date when Django was started and not the date in
wich this method is called, and the date I intend to get is the one when the
method is called. I think that I shouldn't call datetime.date.today() as a
default value for the method's parameters.

Cheers,
Felix.

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


[issue2771] Test issue

2019-02-11 Thread Antoine Pitrou


Antoine Pitrou  added the comment:

notifying a lot of people

--

___
Python tracker 

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



[issue2771] Test issue

2019-02-11 Thread Ernest W. Durbin III


Ernest W. Durbin III  added the comment:

test

--

___
Python tracker 

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



[issue35963] Python/symtable.c: warning: enumeration value ‘FunctionType_kind’ not handled in switch [-Wswitch]"

2019-02-11 Thread STINNER Victor


STINNER Victor  added the comment:

Thanks for the fix, Guido ;-)

--

___
Python tracker 

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



RE: more pythonic way

2019-02-11 Thread Felix Lazaro Carbonell
Sorry I meant 
 

..

def find_monthly_expenses(month=None, year=None):

month = month or datetime.date.today().month

..
 

Or it should better be:

...

if not month:

month = datetime.date.today().month

..
 

Cheers,

Felix.

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

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


Re: more pythonic way

2019-02-11 Thread Grant Edwards
On 2019-02-11, Felix Lazaro Carbonell  wrote:

> Could you please tell me wich way of writing this method is more pythonic:
>
> def find_monthly_expenses(month=None, year=None):
> month = month or datetime.date.today()
>
> Or it should better be:
>
> if not month:
> month = datetime.date.today()

The most pythonic way is to do this:

   def find_monthly_expenses(month=datetime.date.today().month, 
year=datetime.date.today().year):
  ...

And then start a month-long argument on the mailing list about how the
behavior of parameter default values is wrong and needs be changed.

;)

-- 
Grant Edwards   grant.b.edwardsYow! I always have fun
  at   because I'm out of my
  gmail.commind!!!

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


more pythonic way

2019-02-11 Thread Felix Lazaro Carbonell
 

Hello to everyone:

Could you please tell me wich way of writing this method is more pythonic:

 

..

def find_monthly_expenses(month=None, year=None):

month = month or datetime.date.today()

..

 

Or it should better be:

...

if not month:

month = datetime.date.today()

..

 

Cheers,

Felix.

 

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


[issue35963] Python/symtable.c: warning: enumeration value ‘FunctionType_kind’ not handled in switch [-Wswitch]"

2019-02-11 Thread Guido van Rossum


Guido van Rossum  added the comment:


New changeset 522346d792d9013140a3f4ad3534ac10f38d9085 by Guido van Rossum in 
branch 'master':
Complete switch cases in symtable.c; fixes bpo-35963 (GH-11821)
https://github.com/python/cpython/commit/522346d792d9013140a3f4ad3534ac10f38d9085


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



Re: Can't run setup.py offline due to setup_requires - setup.py calls home

2019-02-11 Thread Chris Narkiewicz via Python-list
On 11/02/2019 15:57, Ben Finney wrote:
> All of the build dependencies, *including* the ones specified in
> ‘setup_requires’?

Yes. easy_install simply doesn't look there. If I provide
~/.pydistutils.cfg with a path to find_links, it works ok.

Config file in $HOME however is no-go for a CI or build servers, as I
have no control over automated build environment (launchpad.net in this
case).

> To avoid the Setuptools bug, the PyPA recommends dropping the
> ‘setup_requires’ option and instead specifying build dependencies in a
> PEP 518 formatted metadata file
> https://github.com/pypa/setuptools/issues/293>.

Ok, I took Automat-0.7.tar.gz package and I modified it:
1) removed setup_requires
2) added pyproject.toml with content:

[build-system]
requires = ["setuptools-scm", "m2r"]

3) package is dropped into pypi directory with all dependencies.

However, when I try to install Automat from source, it doesn't work.

(venv)$ pip3 install --no-index --find-links=pypi --no-binary=':all:'
--no-cache Automat

I see that those build-time dependencies are not installed and build
complains about missing scm and m2r packages.

Is there any extra step I have to take?

Best regards,
Chris



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


[issue2771] Test issue

2019-02-11 Thread Ernest W. Durbin III


Ernest W. Durbin III  added the comment:

should be fast send.

--

___
Python tracker 

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



[issue35813] shared memory construct to avoid need for serialization between processes

2019-02-11 Thread Davin Potts


Davin Potts  added the comment:

@terry.reedy and @ronaldoussoren: I have asked Van again to provide comments 
here clarifying the topics of (1) copyright notices and (2) requiring the 
BSD-licensed-work's author to sign a contributor agreement.

Specifically regarding the appearance of __copyright__, I added my agreement to 
your comments on GH-11816 on this.

--

___
Python tracker 

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



Re: Replicating YouTube video AI code in python

2019-02-11 Thread Abdur-Rahmaan Janhangeer
what python version are you using? what errors are you getting?

Abdur-Rahmaan Janhangeer
http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list


Replicating YouTube video AI code in python

2019-02-11 Thread jadenfigger
I'm trying to replicate the YouTube video,  
https://m.youtube.com/watch?v=NTlXEJjfsQU. The videos git hub address is, 
https://github.com/carykh/alignedCelebFaces. The video says I have to download 
python 3 and using pip download tensorflow, numpy, scipy, and pygame. I've 
tried downloading this but keep getting errors when trying to download the 
packages with pip. If anyone could show me a good tutorial or show me the steps 
that would be great. Thank you
-- 
https://mail.python.org/mailman/listinfo/python-list


[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

2019-02-11 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

Sorry by previous reports I was talking about some of the issues where the 
installers were not correct though I couldn't find the issue at the moment. I 
just presented it as a data point where some necessary modules that cannot be 
imported could lead to crash. But if this can be dealt with in a better way I 
think it will be a good improvement.

--

___
Python tracker 

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



Re: Im trying to replicate the youtube video Creating my own customized celebrities with AI.

2019-02-11 Thread Peter J. Holzer
On 2019-02-10 16:28:24 -0500, Avi Gross wrote:
> >> tenserflow, pygame, scipy, and numby
[...]
> please mention that the tenser flow should be tensorflow.

Eight, sir; seven, sir;
Six, sir; five, sir;
Four, sir; three, sir;
Two, sir; one!
Tenser, said the Tensor.
Tenser, said the Tensor.
Tension, apprehension,
And dissention have begun.

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


[issue2771] Test issue

2019-02-11 Thread Ernest W. Durbin III


Ernest W. Durbin III  added the comment:

test mail sending

--

___
Python tracker 

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



Re: where is math_sin defined?

2019-02-11 Thread Barry Scott



> On 10 Feb 2019, at 16:43, Chris Angelico  wrote:
> 
> On Mon, Feb 11, 2019 at 3:37 AM Barry Scott  wrote:
>> 
>> On Sunday, 10 February 2019 15:15:32 GMT Jon Ribbens wrote:
>>> As an aside, how is 'math.sin' actually implemented? mathmodule.c
>>> refers to the function 'math_sin' but that name is not defined
>>> anywhere in the Python source code. I'm a bit mystified as to how
>>> CPython manages to compile!
>> 
>> I used gdb to find it:
>> 
> 
> Effective, if a little tedious.

Tedious? Its fast and accurate only took 20s and got the answer right first 
time.

I had spent a few minutes reading and greping the code and my grep fu found to 
many false positives.

Barry

> 
> My technique was to first confirm that there was nothing saying
> "math_sin" anywhere in the repo (trust but verify - doesn't hurt to do
> a quick "git grep"), then to search mathmodule.c for "sin(", since
> searching for "sin" on its own gave way too many hits. That led me to
> the definition of sinpi(), then to asin() and sin(), both being
> defined using the FUNC1 template.
> 
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

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


[issue35955] difflib reports incorrect location of mismatch

2019-02-11 Thread Karthikeyan Singaravelan

Karthikeyan Singaravelan  added the comment:

Thanks for the explanation. This seems to give the desired diff with 
charjunk=None passed to multiline string comparison helper. I am not sure how 
useful it would be to pass it to sequence and dict comparison that also use 
ndiff. I can open a PR if it's okay with the set of strings in the report as a 
test case. There are no test case failures in existing unittest folder test 
suite so this seems like a safe change to me.


# With patch charjunk=None

./python.exe ../backups/bpo35955_1.py
F
==
FAIL: test_foo (__main__.FooTestCase)
--
Traceback (most recent call last):
  File "../backups/bpo35955_1.py", line 6, in test_foo
self.assertEqual("drwxrwxr-x 2 2000  2000\n", "drwxr-xr-x 2 2000  2000\n")
AssertionError: 'drwxrwxr-x 2 2000  2000\n' != 'drwxr-xr-x 2 2000  2000\n'
- drwxrwxr-x 2 2000  2000
?  ^
+ drwxr-xr-x 2 2000  2000
?  ^


--
Ran 1 test in 0.003s

FAILED (failures=1)

# Without patch

➜  cpython git:(master) ✗ python3.7 ../backups/bpo35955_1.py
F
==
FAIL: test_foo (__main__.FooTestCase)
--
Traceback (most recent call last):
  File "../backups/bpo35955_1.py", line 6, in test_foo
self.assertEqual("drwxrwxr-x 2 2000  2000\n", "drwxr-xr-x 2 2000  2000\n")
AssertionError: 'drwxrwxr-x 2 2000  2000\n' != 'drwxr-xr-x 2 2000  2000\n'
- drwxrwxr-x 2 2000  2000
?  ---
+ drwxr-xr-x 2 2000  2000
?+++


--
Ran 1 test in 0.002s

FAILED (failures=1)

--

___
Python tracker 

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



[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

2019-02-11 Thread Paul Ganssle


Paul Ganssle  added the comment:

@Karthikeyan I would certainly consider this a duplicate of the encodings 
bug/behavior that you demonstrate. I don't see an existing bug on the tracker 
for it, though.

I think it's pretty clear that the interpreter needs to fail, but it seems to 
*crash* rather than exit gracefully with a non-zero return code, which I think 
is the main problem. I'll note that it *does* print some stuff out before it 
crashes, which makes me think that even though io and/or encodings hasn't 
loaded, you still are able to do the "print an error message" part of "print an 
error message and exit with non-zero error code".

--

___
Python tracker 

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



[issue35970] no help flag in base64 util

2019-02-11 Thread Robert Kuska


New submission from Robert Kuska :

I failed today to print help message for base64 utility without an error:

 $ python3 -m base64 -help
option -h not recognized
usage: 
/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/base64.py
 [-d|-e|-u|-t] [file|-]
-d, -u: decode
-e: encode (default)
-t: encode and decode string 'Aladdin:open sesame

So I felt like this is a ripple in time space continuum worth adjusting.

I already opened a PR to address this (probably not so worthy) issue (link 
attached).

--
messages: 335255
nosy: rkuska
priority: normal
pull_requests: 11851
severity: normal
status: open
title: no help flag in base64 util

___
Python tracker 

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



[issue2771] Test issue

2019-02-11 Thread Ernest W. Durbin III


Ernest W. Durbin III  added the comment:

test comment

--

___
Python tracker 

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



[issue2771] Test issue

2019-02-11 Thread Ernest W. Durbin III


Ernest W. Durbin III  added the comment:

comment on test issue to test the request time.

--

___
Python tracker 

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



[issue35955] difflib reports incorrect location of mismatch

2019-02-11 Thread Tim Peters


Tim Peters  added the comment:

difflib generally synchs on the longest contiguous matching subsequence that 
doesn't contain a "junk" element.  By default, `ndiff()`'s optional `charjunk` 
argument considers blanks and tabs to be junk characters.

In the strings:

"drwxrwxr-x 2 2000  2000\n"
"drwxr-xr-x 2 2000  2000\n"

the longest matching substring not containing whitespace is "rwxr-x", of length 
6, starting at index 4 in the first string and at index 1 in the second.  So 
it's aligning the strings like so:

"drwxrwxr-x 2 2000  2000\n"
   "drwxr-xr-x 2 2000  2000\n"
 123456

That's why it wants to delete the 1:4 slice in the first string and insert 
"r-x" after the longest matching substring.

The default is aimed at improving results for human-readable text, like prose 
and Python code, where stuff between whitespace is often read "as a whole" 
(words, keywords, identifiers, ...).

For cases like this one, where character-by-character differences are 
important, it's often better to pass `charjunk=None`.  Then the longest 
matching substring is "xr-x 2 2000  2000" at the tail end of both strings, and 
you get the output you're expecting.

--

___
Python tracker 

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



[issue35967] Better platform.processor support

2019-02-11 Thread Ned Deily


Change by Ned Deily :


--
nosy: +lemburg

___
Python tracker 

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



[issue23460] Decimals do not obey ':g' exponential notation formatting rules

2019-02-11 Thread Brennan D Baraban


Brennan D Baraban <3...@holbertonschool.com> added the comment:

Well, Tuomas, I defer submission of a PR to you, as its your original patch.

--

___
Python tracker 

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



[issue35968] lib2to3 cannot parse rf''

2019-02-11 Thread Ned Deily


Ned Deily  added the comment:

@xtreak, I concur.  While it would have better to originally fix this in the 
release where f strings first appeared, the window to do that has closed.  
Sorry!

--
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> 2to3 doesn't parse all valid string literals

___
Python tracker 

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



[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

2019-02-11 Thread Karthikeyan Singaravelan

Karthikeyan Singaravelan  added the comment:

I hope there are certain modules that CPython interpreter expects to load 
properly. There were some cases in the past where encodings module caused the 
interpreter to crash. A similar scenario.

➜  cpython git:(master) echo "raise Exception('a')" > encodings.py
➜  cpython git:(master) ✗ PYTHONPATH=: ./python.exe
Fatal Python error: initfsencoding: failed to get the Python codec of the 
filesystem encoding
Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/encodings.py", line 
1, in 
Exception: a
[1]29005 abort  PYTHONPATH=: ./python.exe

--
nosy: +xtreak

___
Python tracker 

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



[issue35955] difflib reports incorrect location of mismatch

2019-02-11 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

I am not sure this is a duplicate since the other issue was about newline at 
the end of strings. This is about the diff being little irrelevant even with 
newline in the end for strings. Sample program where change in 5th character 
gives the reported diff.

import difflib

for i in range(7):
print(f"Change character at {i}")
a = list("drwxrwxr-x 2 2000  2000\n")
b = "drwxrwxr-x 2 2000  2000\n"
a[i] = '-'
a = ''.join(a)
print(''.join(difflib.ndiff([a], [b])))

Change character at 0
- -rwxrwxr-x 2 2000  2000
? ^
+ drwxrwxr-x 2 2000  2000
? ^

Change character at 1
- d-wxrwxr-x 2 2000  2000
?  ^
+ drwxrwxr-x 2 2000  2000
?  ^

Change character at 2
- dr-xrwxr-x 2 2000  2000
?   ^
+ drwxrwxr-x 2 2000  2000
?   ^

Change character at 3
- drw-rwxr-x 2 2000  2000
?^
+ drwxrwxr-x 2 2000  2000
?^

Change character at 4
- drwx-wxr-x 2 2000  2000
? ^
+ drwxrwxr-x 2 2000  2000
? ^

Change character at 5
- drwxr-xr-x 2 2000  2000
?---
+ drwxrwxr-x 2 2000  2000
?  +++

Change character at 6
- drwxrw-r-x 2 2000  2000
?   ^
+ drwxrwxr-x 2 2000  2000
?   ^

--

___
Python tracker 

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



[issue35955] difflib reports incorrect location of mismatch

2019-02-11 Thread Jason R. Coombs


Jason R. Coombs  added the comment:

I don't think so, because the issue happens on a single line diff... although 
it's plausible there's a common-mode fix.

--

___
Python tracker 

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



[issue35955] difflib reports incorrect location of mismatch

2019-02-11 Thread Chris Jerdonek


Chris Jerdonek  added the comment:

Is this a duplicate of issue24780?

--
nosy: +chris.jerdonek

___
Python tracker 

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



Zato blog post: A successful Python 3 migration story

2019-02-11 Thread Terry Reedy

The migration was from 2.7 to 2.7 and 3.x, rather than 3.x only.
I think it worth reading for anyone interested in the subject.
https://zato.io/blog/posts/python-3-migration-success-story.html

60,000 lines of Python and Cython, 130 external dependencies (but only 
10 not already 3.x ready) took 2 people 80 hours total.


Their head start was to write the 2.7 modules, from the beginning, with 
the following at the top.
from __future__ import absolute_import, division, print_function, 
unicode_literals



--
Terry Jan Reedy

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


[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

2019-02-11 Thread Paul Ganssle


Paul Ganssle  added the comment:

Tested with 3.6 and 2.7 - core dump on 3.6, no core dump on 2.7. The crash on 
2.7 goes through a different path, it goes site.py > os.py >= UserDict.py > 
_abcoll.py > abc.py. That may account for why it's not crashing the interpreter 
itself.

--
versions: +Python 3.6 -Python 2.7

___
Python tracker 

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



[issue35969] Interpreter crashes with "can't initialize init_sys_streams" when abc fails to import

2019-02-11 Thread Paul Ganssle


New submission from Paul Ganssle :

Just noticed this (tested on Python 3.7 and 3.8):

mkdir /tmp/demo
cd /tmp/demo
cat << EOF > abc.py
raise Exception("Hi")
EOF
PYTHONPATH=: python -c ""


This will crash the interpreter with:

Fatal Python error: init_sys_streams: can't initialize sys standard 
streams
Traceback (most recent call last):
  File ".../lib/python3.7/io.py", line 52, in 
  File "/tmp/demo/abc.py", line 1, in 
Exception: Hi
Aborted (core dumped)


It seems that the problem is that the io module imports the abc module, which 
raises an exception, so io fails to load. Evidently the io module is necessary 
to load the interpreter, so the interpreter crashes.

Here's the backtrace for 3.7.2 on Arch Linux:

(gdb) bt
#0  0x7f234b3f0d7f in raise () from /usr/lib/libc.so.6
#1  0x7f234b3db672 in abort () from /usr/lib/libc.so.6
#2  0x7f234b7db490 in fatal_error (prefix=prefix@entry=0x7f234b9d5fe0 
<__func__.16645> "init_sys_streams", 
msg=msg@entry=0x7f234ba01f60 "can't initialize sys standard streams", 
status=status@entry=-1)
at Python/pylifecycle.c:2179
#3  0x7f234b8460cb in _Py_FatalInitError (err=...) at 
Python/pylifecycle.c:2198
#4  0x7f234b8495a9 in pymain_init (pymain=0x7fff971cca70) at 
Modules/main.c:3019
#5  0x555dfa560050 in ?? ()
#6  0x7fff971ccbc0 in ?? ()
#7  0x in ?? ()


I'm not sure if anything can or should be done about this. It's very fair for 
the interpreter to fail to start, though I would guess that it should do that 
without dumping a core.

--
messages: 335244
nosy: p-ganssle
priority: normal
severity: normal
status: open
title: Interpreter crashes with "can't initialize init_sys_streams" when abc 
fails to import
type: crash
versions: Python 2.7, 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



[issue35965] Behavior for unittest.assertRaisesRegex differs depending on whether it is used as a context manager

2019-02-11 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

No problem, after some debugging the statement finally executed is 
'exec(compile("set.add(0)", "foo.py", "exec"))' . In Python interpreter this 
will give the expected error. It also gives the same error before 
coverage.start() [0] and gives a different one as in the report once the 
statement is executed after coverage.start(). So this might be something to do 
with coverage and I have less knowledge about the internals.

I am closing this as third party since I couldn't see any issue with CPython 
and you might want to follow up coverage issue tracker. Thanks for the report 
though!

[0] 
https://github.com/nedbat/coveragepy/blob/f12db7fd4b3ab288f7f770f7138062951feaa6c9/coverage/cmdline.py#L639

--
resolution:  -> third party
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



[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

2019-02-11 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


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



[issue35378] multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

2019-02-11 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:


New changeset 3766f18c524c57784eea7c0001602017d2122156 by Pablo Galindo in 
branch 'master':
bpo-35378: Fix multiprocessing.Pool references (GH-11627)
https://github.com/python/cpython/commit/3766f18c524c57784eea7c0001602017d2122156


--

___
Python tracker 

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



[issue35968] lib2to3 cannot parse rf''

2019-02-11 Thread Karthikeyan Singaravelan

Karthikeyan Singaravelan  added the comment:

The reported example works fine on master and 3.7 . The related issue's fix was 
not backported to 3.6 . 3.6 is in security fixes only mode. So upgrading to 3.7 
will help and I propose closing this as a duplicate of issue33266 .

➜  cpython git:(master) ✗ cat foo.py
#!/usr/bin/env python
# -*- coding: utf-8 -*-

regex_format = rf''
➜  cpython git:(master) ✗ ./python.exe ./Tools/scripts/2to3 foo.py
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: No changes to foo.py
RefactoringTool: Files that need to be modified:
RefactoringTool: foo.py
➜  cpython git:(master) ✗ python3.7 ./Tools/scripts/2to3 foo.py
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: No changes to foo.py
RefactoringTool: Files that need to be modified:
RefactoringTool: foo.py
➜  cpython git:(master) ✗ python3.6 ./Tools/scripts/2to3 foo.py
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: Can't parse foo.py: ParseError: bad input: type=3, value="''", 
context=('', (4, 17))
RefactoringTool: No files need to be modified.
RefactoringTool: There was 1 error:
RefactoringTool: Can't parse foo.py: ParseError: bad input: type=3, value="''", 
context=('', (4, 17))

--
nosy: +benjamin.peterson

___
Python tracker 

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



[issue35968] lib2to3 cannot parse rf''

2019-02-11 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

Seems related : issue33266

--
nosy: +xtreak

___
Python tracker 

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



[issue35965] Behavior for unittest.assertRaisesRegex differs depending on whether it is used as a context manager

2019-02-11 Thread SylvainDe


SylvainDe  added the comment:

I have no explanation whatsoever but removing the call to coverage seems to 
remove the issue: 
https://travis-ci.org/SylvainDe/DidYouMean-Python/builds/491727724 .

I guess we can close this issue - sorry for the inconvenience.

@nedbat: do you want me to open an issue in coverage ?

--

___
Python tracker 

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



[issue35968] lib2to3 cannot parse rf''

2019-02-11 Thread Dylan Lloyd


New submission from Dylan Lloyd :

```
#!/usr/bin/env python
# -*- coding: utf-8 -*-

regex_format = rf''
```

```
yapf poc.py
```

```
Traceback (most recent call last):
  File "lib/python3.6/site-packages/yapf/yapflib/pytree_utils.py", line 115, in 
ParseCodeToTree
tree = parser_driver.parse_string(code, debug=False)
  File "lib/python3.6/lib2to3/pgen2/driver.py", line 107, in parse_string
return self.parse_tokens(tokens, debug)
  File "lib/python3.6/lib2to3/pgen2/driver.py", line 72, in parse_tokens
if p.addtoken(type, value, (prefix, start)):
  File "lib/python3.6/lib2to3/pgen2/parse.py", line 159, in addtoken
raise ParseError("bad input", type, value, context)
lib2to3.pgen2.parse.ParseError: bad input: type=3, value="''", context=('', (4, 
17))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "bin/yapf", line 10, in 
sys.exit(run_main())
  File "lib/python3.6/site-packages/yapf/__init__.py", line 326, in run_main
sys.exit(main(sys.argv))
  File "lib/python3.6/site-packages/yapf/__init__.py", line 213, in main
verbose=args.verbose)
  File "lib/python3.6/site-packages/yapf/__init__.py", line 263, in FormatFiles
in_place, print_diff, verify, verbose)
  File "lib/python3.6/site-packages/yapf/__init__.py", line 289, in _FormatFile
logger=logging.warning)
  File "lib/python3.6/site-packages/yapf/yapflib/yapf_api.py", line 91, in 
FormatFile
verify=verify)
  File "lib/python3.6/site-packages/yapf/yapflib/yapf_api.py", line 129, in 
FormatCode
tree = pytree_utils.ParseCodeToTree(unformatted_source)
  File "lib/python3.6/site-packages/yapf/yapflib/pytree_utils.py", line 121, in 
ParseCodeToTree
tree = parser_driver.parse_string(code, debug=False)
  File "lib/python3.6/lib2to3/pgen2/driver.py", line 107, in parse_string
return self.parse_tokens(tokens, debug)
  File "lib/python3.6/lib2to3/pgen2/driver.py", line 72, in parse_tokens
if p.addtoken(type, value, (prefix, start)):
  File "lib/python3.6/lib2to3/pgen2/parse.py", line 159, in addtoken
raise ParseError("bad input", type, value, context)
lib2to3.pgen2.parse.ParseError: bad input: type=3, value="''", context=('', (4, 
17))
```

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 335238
nosy: majuscule
priority: normal
severity: normal
status: open
title: lib2to3 cannot parse rf''
type: crash
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



Re: exit 2 levels of if/else and execute common code

2019-02-11 Thread Neal Becker
Chris Angelico wrote:

> On Tue, Feb 12, 2019 at 3:21 AM Neal Becker  wrote:
>>
>> Chris Angelico wrote:
>>
>> > On Tue, Feb 12, 2019 at 2:27 AM Neal Becker 
>> > wrote:
>> >>
>> >> I have code with structure:
>> >> ```
>> >> if cond1:
>> >>   [some code]
>> >>   if cond2: #where cond2 depends on the above [some code]
>> >> [ more code]
>> >>
>> >>   else:
>> >> [ do xxyy ]
>> >> else:
>> >>   [ do the same xxyy as above ]
>> >> ```
>> >>
>> >> So what's the best style to handle this?  As coded, it violates DRY.
>> >> Try/except could be used with a custom exception, but that seems a bit
>> >> heavy
>> >> handed.  Suggestions?
>> >
>> > One common way to do this is to toss a "return" after the cond2 block.
>> > Means this has to be the end of a function, but that's usually not
>> > hard. Or, as Rhodri suggested, refactor xxyy into a function, which
>> > you then call twice.
>> >
>> > ChrisA
>>
>> Not bad, but turns out it would be the same return statement for both the
>> normal return path (cond1 and cond2 satisfied) as well as the abnormal
>> return, so not really much of an improvement.
> 
> Not sure what you mean there. The result would be something like this:
> 
> def frobnicate():
> if cond1:
> do_stuff()
> if cond2:
> do_more_stuff()
> return
> do_other_stuff()
> 
> ChrisA
sorry, I left out the return:

if cond1:
   [some code]
   if cond2: #where cond2 depends on the above [some code]
 [ more code]

   else:
 [ do xxyy ]
else:
   [ do the same xxyy as above ]
return a, b, c

So if we return normally, or return via some other path, the return 
statement is the same, and would be duplicated.

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


Re: exit 2 levels of if/else and execute common code

2019-02-11 Thread Irv Kalb


> On Feb 11, 2019, at 7:25 AM, Neal Becker  wrote:
> 
> I have code with structure:
> ```
> if cond1:
>  [some code]
>  if cond2: #where cond2 depends on the above [some code]
>[ more code]
> 
>  else:
>[ do xxyy ]
> else:
>  [ do the same xxyy as above ]
> ```
> 
> So what's the best style to handle this?  As coded, it violates DRY.  
> Try/except could be used with a custom exception, but that seems a bit heavy 
> handed.  Suggestions?
> 

I like the additional function approach others have mentioned.  But if you want 
a different approach, you could do this:

runExtraCode = True# set some Boolean
if cond1:
[some code]
if cond2:
[more code]
runExtraCode = False  # both conditions met, no need to run the extra 
code

if runExtraCode:
[do xxyy]


Irv

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


Re: exit 2 levels of if/else and execute common code

2019-02-11 Thread Chris Angelico
On Tue, Feb 12, 2019 at 3:21 AM Neal Becker  wrote:
>
> Chris Angelico wrote:
>
> > On Tue, Feb 12, 2019 at 2:27 AM Neal Becker  wrote:
> >>
> >> I have code with structure:
> >> ```
> >> if cond1:
> >>   [some code]
> >>   if cond2: #where cond2 depends on the above [some code]
> >> [ more code]
> >>
> >>   else:
> >> [ do xxyy ]
> >> else:
> >>   [ do the same xxyy as above ]
> >> ```
> >>
> >> So what's the best style to handle this?  As coded, it violates DRY.
> >> Try/except could be used with a custom exception, but that seems a bit
> >> heavy
> >> handed.  Suggestions?
> >
> > One common way to do this is to toss a "return" after the cond2 block.
> > Means this has to be the end of a function, but that's usually not
> > hard. Or, as Rhodri suggested, refactor xxyy into a function, which
> > you then call twice.
> >
> > ChrisA
>
> Not bad, but turns out it would be the same return statement for both the
> normal return path (cond1 and cond2 satisfied) as well as the abnormal
> return, so not really much of an improvement.

Not sure what you mean there. The result would be something like this:

def frobnicate():
if cond1:
do_stuff()
if cond2:
do_more_stuff()
return
do_other_stuff()

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


Re: exit 2 levels of if/else and execute common code

2019-02-11 Thread Neal Becker
Chris Angelico wrote:

> On Tue, Feb 12, 2019 at 2:27 AM Neal Becker  wrote:
>>
>> I have code with structure:
>> ```
>> if cond1:
>>   [some code]
>>   if cond2: #where cond2 depends on the above [some code]
>> [ more code]
>>
>>   else:
>> [ do xxyy ]
>> else:
>>   [ do the same xxyy as above ]
>> ```
>>
>> So what's the best style to handle this?  As coded, it violates DRY.
>> Try/except could be used with a custom exception, but that seems a bit
>> heavy
>> handed.  Suggestions?
> 
> One common way to do this is to toss a "return" after the cond2 block.
> Means this has to be the end of a function, but that's usually not
> hard. Or, as Rhodri suggested, refactor xxyy into a function, which
> you then call twice.
> 
> ChrisA

Not bad, but turns out it would be the same return statement for both the 
normal return path (cond1 and cond2 satisfied) as well as the abnormal 
return, so not really much of an improvement.

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


[issue35965] Behavior for unittest.assertRaisesRegex differs depending on whether it is used as a context manager

2019-02-11 Thread SylvainDe


SylvainDe  added the comment:

This is a brilliant idea! I'll give it a try and keep you posted.

--

___
Python tracker 

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



[issue35963] Python/symtable.c: warning: enumeration value ‘FunctionType_kind’ not handled in switch [-Wswitch]"

2019-02-11 Thread Guido van Rossum


Change by Guido van Rossum :


--
keywords: +patch, patch, patch
pull_requests: +11848, 11849, 11850
stage:  -> patch review

___
Python tracker 

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



[issue35963] Python/symtable.c: warning: enumeration value ‘FunctionType_kind’ not handled in switch [-Wswitch]"

2019-02-11 Thread Guido van Rossum


Change by Guido van Rossum :


--
keywords: +patch, patch
pull_requests: +11848, 11849
stage:  -> patch review

___
Python tracker 

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



[issue35963] Python/symtable.c: warning: enumeration value ‘FunctionType_kind’ not handled in switch [-Wswitch]"

2019-02-11 Thread Guido van Rossum


Change by Guido van Rossum :


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

___
Python tracker 

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



[issue35963] Python/symtable.c: warning: enumeration value ‘FunctionType_kind’ not handled in switch [-Wswitch]"

2019-02-11 Thread Guido van Rossum


Guido van Rossum  added the comment:

Sure, I'll fix it.

--

___
Python tracker 

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



  1   2   >