[issue24583] set.update(): Crash when source set is changed during merging

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue24583] set.update(): Crash when source set is changed during merging

[Roundup Robot]

Roundup Robot added the comment:

New changeset 5c3812412b6f by Raymond Hettinger in branch '3.5':
Issue #24583: Fix crash when set is mutated while being updated.
https://hg.python.org/cpython/rev/5c3812412b6f

New changeset 05cb67dab161 by Raymond Hettinger in branch 'default':
Issue #24583: Fix crash when set is mutated while being updated.
https://hg.python.org/cpython/rev/05cb67dab161

--
nosy: +python-dev

___
Python tracker 

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

[issue23601] use small object allocator for dict key storage

[Stefan Behnel]

Stefan Behnel added the comment:

Benchmark results look good to me (although a header line is missing) and seem 
to match my expectations. Sounds like we should allow this change.

--

___
Python tracker 

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

[issue24508] Backport 3.5's Windows build project files to 2.7

[Roundup Robot]

Roundup Robot added the comment:

New changeset ca78b9449e04 by Zachary Ware in branch '2.7':
Close #24508: Backport the 3.5 MSBuild project files.
https://hg.python.org/cpython/rev/ca78b9449e04

--
nosy: +python-dev
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

[issue23963] Windows build error using original openssl source

[Zachary Ware]

Zachary Ware added the comment:

bcf93e3766e8 applied cleanly to 2.7, so I just used it.

Thanks for the report, and sorry it took so long to fix!

--
assignee:  -> zach.ware

___
Python tracker 

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

[issue23963] Windows build error using original openssl source

[Roundup Robot]

Roundup Robot added the comment:

New changeset d1f4d14bd550 by Zachary Ware in branch '2.7':
Close #23963: Fix building with original OpenSSL sources.
https://hg.python.org/cpython/rev/d1f4d14bd550

--
nosy: +python-dev
resolution:  -> fixed
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

[issue24635] test_typing is flaky

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue23247] Crash in the reset() method of StreamWriter of CJK codecs

[Aaron Hill]

Aaron Hill added the comment:

The patch didn't get attached for some reason. It's attached now.

--
Added file: http://bugs.python.org/file39933/fix-multibytecodec-segfault.patch

___
Python tracker 

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

[issue23247] Crash in the reset() method of StreamWriter of CJK codecs

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

cjk_codecs_reset.patch LGTM.

--
assignee: serhiy.storchaka -> haypo
stage:  -> test needed

___
Python tracker 

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

[issue23247] Crash in the reset() method of StreamWriter of CJK codecs

[Aaron Hill]

Aaron Hill added the comment:

The included patch fixes the issue, and modifies the existing unittest to 
prevent a future regression.

The patch corrects an issue where the 'pending' struct field was NULL, but was 
used as the input to multibytecodec_encode anyay.

--

___
Python tracker 

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

[issue24626] please sync cgi.parse document

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +berker.peksag

___
Python tracker 

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

[issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder

[Martin Panter]

Changes by Martin Panter :


--
dependencies: +Fix codecs.iterencode/decode() by allowing data parameter to be 
omitted
stage:  -> patch review

___
Python tracker 

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

[issue23661] Setting a exception side_effect on a mock from create_autospec does not work

[Berker Peksag]

Changes by Berker Peksag :


--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

___
Python tracker 

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

[issue23247] Crash in the reset() method of StreamWriter of CJK codecs

[Martin Panter]

Martin Panter added the comment:

Perhaps this test case proposed in my patch for Issue 13881 could be useful:

+def test_writer_reuse(self):
+"""StreamWriter should be reusable after reset"""

Looks like that is where my “broken_stream_codecs” list from the original post 
came from.

--

___
Python tracker 

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

[issue23247] Crash in the reset() method of StreamWriter of CJK codecs

[STINNER Victor]

STINNER Victor added the comment:

> It looks like there was no test for this specific bug :-/ Calling reset() 
> just after creating a StreamReader object.

Oops: StreamWriter, not StreamReader.

--

___
Python tracker 

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

[issue23247] Crash in the reset() method of StreamWriter of CJK codecs

[STINNER Victor]

STINNER Victor added the comment:

> Happens for all the multibyte codecs: (...)

All these codecs share the same C implementation: the "CJK" codecs.

The bug was introduced in Python 3.4 by my huge changeset d621bdaed7c3: Issue 
"#17693: CJK encoders now use the new Unicode API (PEP 393)".

It looks like there was no test for this specific bug :-/ Calling reset() just 
after creating a StreamReader object.

Attached patch should fix the crash.

@Aaron1011: Can you please try to write a patch adding a unit test to 
test_codecs reproducing the crash?

--
keywords: +patch
title: Multibyte codec StreamWriter.reset() crashes -> Crash in the reset() 
method of StreamWriter of CJK codecs
versions: +Python 3.5
Added file: http://bugs.python.org/file39932/cjk_codecs_reset.patch

___
Python tracker 

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

[issue23247] Multibyte codec StreamWriter.reset() crashes

[Aaron Hill]

Aaron Hill added the comment:

This is also present in the latest Python 3.6.

I'm going to work on providing a patch for this, unless someone else already is

--
nosy: +Aaron1011
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

[issue23926] skipitem() in getargs.c still supports 'w' and 'w#', and shouldn't

[Joe Jevnik]

Joe Jevnik added the comment:

Sorry it took so long to get back to this. I didn't realize this was still 
open. I have provided the update to the docs and moved it to the 3.6 section. I 
also made sure the patch still applies and the tests all pass.

--
Added file: http://bugs.python.org/file39931/skipitems.patch

___
Python tracker 

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

[issue23972] Asyncio reuseport

[STINNER Victor]

STINNER Victor added the comment:

A quick search told me that "Windows only knows the SO_REUSEADDR option, there 
is no SO_REUSEPORT". It should be at least documented that SO_REUSEADDR is not 
supported on Windows.

Maybe we should raise an exception on Windows if reuse_port=True? Ignoring the 
parameter is a different option, but it should be well documented that the 
option is ignored if socket.SO_REUSEPORT is not defined.

--

___
Python tracker 

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

[issue24640] no ensurepip in embedded Windows distribution

[Chris Krycho]

Chris Krycho added the comment:

Using --root or --target (as appropriate to the specific package) does appear 
to be the preferred approach for that, and given the constraints of an embedded 
installation, I agree that that's the most reasonable solution. I spent a fair 
bit of time reading up on that and the other options, and can't see a better 
one. I've already verified that approach will work for us, so I imagine it 
should for others as well.

--

___
Python tracker 

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

[issue24640] no ensurepip in embedded Windows distribution

[STINNER Victor]

Changes by STINNER Victor :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python

___
Python tracker 

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

[issue24640] no ensurepip in embedded Windows distribution

[Steve Dower]

Steve Dower added the comment:

It's a deliberate exclusion, I just haven't gotten to all the documentation yet 
(mostly because I still expect things to change).

My idea was that packages would be deployed statically alongside the embedded 
distribution rather than going into a site-packages directory (which should 
also be missing). Obviously this needs to be written up, but it may not be 
reasonable.

To automate packaging you probably want to use a separate pip to install into a 
temporary directory (--root option? I forget the option right now) and bundle 
that up. Does that sound feasible for you?

--

___
Python tracker 

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

[issue24641] Log type of unserializable value when raising JSON TypeError

[Madison May]

New submission from Madison May:

Currently the json lib only logs the string representation of the variable, 
which does not always include type information.

I recently ran into a difficult to debug issue with code similar to the 
following:

```
import json
import numpy as np
d = {'data': np.int16(5)}
json.dumps(d)
```

which produces the following error:

```
TypeError: 5 is not JSON serializable
```

It took us quite a while to determine that `5` was actually of type `np.int` 
instead of the native type.

A cursory glance at StackOverflow suggests that I'm not alone in running into 
this issue: 
http://stackoverflow.com/questions/10872604/json-dump-throwing-typeerror-is-not-json-serializable-on-seemingly-vali


I'd like to consider modifying the error message to be more similar to the 
following:

```
TypeError: 5 of type `numpy.int16` is not JSON serializable
```

--
components: Library (Lib)
messages: 246776
nosy: Madison May
priority: normal
severity: normal
status: open
title: Log type of unserializable value when raising JSON TypeError
versions: Python 2.7

___
Python tracker 

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

[issue24640] no ensurepip in embedded Windows distribution

[STINNER Victor]

Changes by STINNER Victor :


--
components: +Windows
nosy: +paul.moore, tim.golden, zach.ware

___
Python tracker 

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

[issue24640] no ensurepip in embedded Windows distribution

[Chris Krycho]

New submission from Chris Krycho:

There is no `ensurepip` module bundled with the embedded distribution of Python 
3.5 for Windows:

Z:\python-3.5.0b3-embed> .\python -m ensurepip --upgrade
Z:\python-3.5.0b3-embed\python.exe: No module named ensurepip

This may be the *intent*, but I haven't been able to find any documentation to 
that effect in the [docs](https://docs.python.org/3.5/library/ensurepip.html). 
It looks like it should either be included with the distribution or noted as 
excluded in the docs. (I can readily submit a patch to the latter if it needs 
doing.)

(Background: I'm looking at various ways to bundle up and ship a Python 
application, and as part of that am looking at just shipping the embedded 
Python distribution, which may end up being the most straightforward for us. 
One of the things I'm still sorting out is the best to get and bundle up 
dependencies if that's the approach we take.)

--
components: Installation
messages: 246775
nosy: chriskrycho, dstufft, ncoghlan, steve.dower
priority: normal
severity: normal
status: open
title: no ensurepip in embedded Windows distribution
type: behavior
versions: Python 3.5

___
Python tracker 

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

[issue8106] SSL session management

[Mladen Milosevic]

Changes by Mladen Milosevic :


--
nosy: +mladen.milosevic

___
Python tracker 

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

[issue24631] Regression in timeit with multyline setup

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: commit 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

[issue24631] Regression in timeit with multyline setup

[Roundup Robot]

Roundup Robot added the comment:

New changeset fce682a493e7 by Serhiy Storchaka in branch '3.5':
Issue #24631: Fixed regression in the timeit modulu with multyline setup.
https://hg.python.org/cpython/rev/fce682a493e7

New changeset 0b04e5689c33 by Serhiy Storchaka in branch 'default':
Issue #24631: Fixed regression in the timeit modulu with multyline setup.
https://hg.python.org/cpython/rev/0b04e5689c33

--
nosy: +python-dev

___
Python tracker 

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

[issue24636] re.search not respecting anchor markers in or-ed construction

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka
resolution:  -> not a bug
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

[issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity

[Charles-François Natali]

Charles-François Natali added the comment:

It's just a doc improvement, I'm not convinced it really needs backporting.

--

___
Python tracker 

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

[issue22858] unittest.__init__:main shadows unittest.main

[Brett Cannon]

Brett Cannon added the comment:

Or deprecate in 3.5 if Larry will let you.

--

___
Python tracker 

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

[issue22858] unittest.__init__:main shadows unittest.main

[Brett Cannon]

Brett Cannon added the comment:

Ah, I see my misunderstanding; when Antoine said "Numba subclasses 
unittest.main" I wasn't thinking and thought he meant something in unitest.main 
the module, not the unittest.main alias for unittest.main.TestProgram which is 
exposed as unitest.__init__.main (yeah, that name clash is nasty).

Then the unittest.main module can be treated like any other module in terms of 
deprecation and doesn't need any special-casing. Sorry about the mix-up on my 
end. So I say rename the modules to _*, add the deprecation to the old names in 
3.6, and then remove the modules in 3.7.

--

___
Python tracker 

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

[issue24631] Regression in timeit with multyline setup

[Brett Cannon]

Brett Cannon added the comment:

Patch LGTM

--
stage: patch review -> commit review

___
Python tracker 

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

[issue24632] Improve documentation about __main__.py

[Ethan Furman]

Ethan Furman added the comment:

RDM noted:
-
> The surprising thing is that __main__ works without there being an
> __init__.  I didn't know that, assumed it wasn't true, and so never
> tried it.

I think this is due to PEP 420 Namespace Packages.

--

___
Python tracker 

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

[issue23972] Asyncio reuseport

[chris laws]

chris laws added the comment:

Attached is a patch that implements the suggested solution along with tests and 
associated doc updates. Hope this helps.

--
keywords: +patch
Added file: http://bugs.python.org/file39930/23972_cjl.patch

___
Python tracker 

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

[issue24632] Improve documentation about __main__.py

[Ezio Melotti]

Ezio Melotti added the comment:

> The surprising thing is that __main__ works without there being an __init__.

That's also what surprised me, I always thought __main__.py was supposed to be 
used within a package executed with "python -m pkg", but apparently "regular" 
dirs and zip files can have one too -- as long as they are executed as "python 
dir_or_zip".


This should have answered the question I posed in my first message: what is 
__main__.py and what is its purpose?

As for the others:
Q: when should it be used?
A: whenever you want to make a package/dir/zip executable
Q: what should it contain?
A: usually an import + a function call that launches the app should be enough, 
but might contain more code if necessary
Q: is it ok to have other __main__.py in the subpackages (e.g. test/__main__.py 
to run the tests with python -m package.test)?
A: this seems to work and should be OK
Q: how it interacts __init__.py (which one is executed first?)
A: __init__.py seems to be executed first.  I'm not aware of other interactions.

If these are indeed correct, a patch can be made (feel free to do it, since I 
don't when I'll have time to do it myself).

--

___
Python tracker 

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

[issue24639] Documentation: broken link on unittest page

[R. David Murray]

R. David Murray added the comment:

This has already been corrected in issue 24548 using a link to archive.org.

--
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Broken link in the unittest documentation
type: performance -> behavior
versions:  -Python 3.2, Python 3.3

___
Python tracker 

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

[issue24638] asyncio "loop argument must agree with future" error message could be improved

[R. David Murray]

New submission from R. David Murray:

I just got the titular error message and had no idea what it meant until I 
looked at the source.  It seems to mean "the specified loop is different from 
the _loop attribute of the future-or-coroutine".  Since _loop is nominally 
private, perhaps the message could be "the future or coroutine belongs to a 
different loop than the one specified as the loop argument".

--
messages: 246763
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: asyncio "loop argument must agree with future" error message could be 
improved

___
Python tracker 

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

[issue24638] asyncio "loop argument must agree with future" error message could be improved

[R. David Murray]

R. David Murray added the comment:

This error message is in tasks.py.

--

___
Python tracker 

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

[issue24639] Documentation: broken link on unittest page

[Ruth Berkow]

New submission from Ruth Berkow:

The documentation for unittest, in the "See also" box contains a link for 
"Simple Smalltalk Testing: With Patterns" that leads to a 404. Replacing this 
with a working link seems like a good idea; may I suggest 
http://live.exept.de/doc/online/english/tools/misc/testfram.htm

--
assignee: docs@python
components: Documentation
messages: 246764
nosy: Ruth Berkow, docs@python
priority: normal
severity: normal
status: open
title: Documentation: broken link on unittest page
type: performance
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost

[Gustavo J. A. M. Carneiro]

Gustavo J. A. M. Carneiro added the comment:

Don't know if it helps, but I made a github pull request for this: 

https://github.com/python/asyncio/pull/256

--

___
Python tracker 

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

[issue24637] locals dictionary in PyRun_String

[Matthew Keeter]

New submission from Matthew Keeter:

The C API docs for PyRun_StringFlags, PyEval_EvalCodeEx, and PyEval_EvalCode 
say that globals and locals both must be dictionaries.  However, digging into 
the source [1] shows that locals can be any object implementing the mapping 
protocol.  Furthermore, the Python docs for eval and exec (which end up taking 
the same path) match the implementation, saying that locals can be any mapping 
object (which has been true since 2.4).

The attached patch changes the C API docs to reflect the Python docs (and the 
actual implementation).  No new tests are required, as test_general_eval [2] 
already checks that an arbitrary mapping object can be used as the locals 
variable in exec.

[1] 
https://github.com/python/cpython/blob/master/Objects/frameobject.c#L628-L629
[2] https://github.com/python/cpython/blob/master/Lib/test/test_builtin.py#L473

--
assignee: docs@python
components: Documentation
files: locals.patch
keywords: patch
messages: 246761
nosy: Matthew Keeter, docs@python
priority: normal
severity: normal
status: open
title: locals dictionary in PyRun_String
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39929/locals.patch

___
Python tracker 

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

[issue24632] Improve documentation about __main__.py

[R. David Murray]

R. David Murray added the comment:

The surprising thing is that __main__ works without there being an __init__.  I 
didn't know that, assumed it wasn't true, and so never tried it.

--

___
Python tracker 

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

[issue24632] Improve documentation about __main__.py

[R. David Murray]

R. David Murray added the comment:

What you just described is exactly what I would have said was the case (a zip 
file acts exactly like it was a directory), so I'm glad that's the way it 
actually works :).

--
nosy: +r.david.murray

___
Python tracker 

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

[issue24632] Improve documentation about __main__.py

[Ezio Melotti]

Ezio Melotti added the comment:

After further tests, I think I figured out how things works.
There are three separate things that interact with each other:
  * packages (dirs with an __init__.py) and "regular" dirs (with no 
__init__.py) or zip files;
  * how python is executed (with or without -m);
  * if the pkg/dir/zip is executed or imported.

__main__.py makes a pkg/dir/zip "executable", but:
  * if it's a package, "python -m pkg" should be used;
  * if it's a dir or zip, "python dir_or_zip" should be used instead.

There seem to be no differences between "regular" dirs and zip files:
  * both can become executable with a __main__.py;
  * both should be executed with "python dir_or_zip" (no -m);
  * both can not be imported (if we ignore namespace packages);
  * both can be added to sys.path, and the modules they contain imported, 
without needing any __main__.py.

This also means that __main__.py is used only while doing "python -m pkg" or 
"python dir_or_zip", and not while doing "import pkg" or while importing a 
module inside a dir/zip.

--

___
Python tracker 

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

[issue24636] re.search not respecting anchor markers in or-ed construction

[Matthew Barnett]

Matthew Barnett added the comment:

The or-ed patterns aren't between the anchors. The ^ is at the start of the 
first alternative and the $ is at the end of the last alternative.

--

___
Python tracker 

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

[issue24636] re.search not respecting anchor markers in or-ed construction

[Almer Tigelaar]

New submission from Almer Tigelaar:

>From the documentation ^ should restrict the matching of re.search to the 
>beginning of the string, as mentioned here: 
>https://docs.python.org/3.4/library/re.html#search-vs-match

However, this doesn't always seem to work as the following example shows:

re.search("^([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9]:[0-5][0-9]\\.[0-9]+)|([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9]:[0-5][0-9])|([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9])|([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9])|([0-9]{4}-[01][0-9]-[0-3][0-9])|([0-9]{4}-[01][0-9])|([0-9]{4})$",
 "2015-AE-02T10:16:08.450904")

This should not match since the expression uses or-ed patterns between anchors 
^ and $. Based on the "AE" this should not return a match, yet it returns one 
from positions 22 to 26, based on the last pattern in the or-red sequence of 
patterns: ([0-9]{4})

This can be worked around by explicitly including the anchor markers in the 
last pattern as follows:

re.search("^([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9]:[0-5][0-9]\\.[0-9]+)|([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9]:[0-5][0-9])|([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9])|([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9])|([0-9]{4}-[01][0-9]-[0-3][0-9])|([0-9]{4}-[01][0-9])|(^[0-9]{4}$)$",
 "2015-AE-02T10:16:08.450904")

Notice: the last pattern now explicitly includes the anchors: (^[0-9]{4}$), 
which is factually duplicate with the anchors that already exist at the 
beginning and end of the entire regular expression!

This work around correctly produces no match (which is the behaviour I expected 
from the first pattern).

--
components: Regular Expressions
messages: 246756
nosy: Almer Tigelaar, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.search not respecting anchor markers in or-ed construction
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue24632] Improve documentation about __main__.py

[Ezio Melotti]

Ezio Melotti added the comment:

Another thing that should be clarified, is the difference between __main__.py 
inside a package, and __main__.py inside a zip file.

For packages, as far as I understand, __main__.py should be inside the package 
(i.e. pkg/__main__.py, in the same dir of pkg/__init__.py).
This allows the package to be "executed" by doing "python3 -m pkg".

For zip files, the __main__.py should be right inside the zip (i.e. 
file.zip/__main__.py).
This allows the zip file to be "executed" by doing "python3 file.zip" (note 
that no -m is used here, and that "python3 -m file.zip" fails).

While zipping a package that already contains a __main__.py, the right way to 
do it seems to be the following:
1) add the package to a zip file (i.e. file.zip/pkg/)
2) add another __main__.py to the zip (i.e. file.zip/__main__.py)
3) add 'import pkg.__main__' to file.zip/__main__.py
now if you do "python3 file.zip", file.zip/__main__.py will be executed, and in 
turn it will import file.zip/pkg/__main__.py, obtaining a result equivalent to 
"python -m pkg".

(I still haven't figured out if the __main__.py is necessary while /importing/ 
a package/module from a zip file, after having added the zip file to sys.path.)

So, to summarize, it seems to me that:
1) pkg/__main__.py is necessary to run "python3 -m pkg" (with -m);
2) file.zip/__main__.py is necessary to run "python3 file.zip" (without -m);
3) due to 1) and 2) creating an executable zipped package requires 2 
__main__.py;
4) "python3 pkg" and "python3 -m file.zip" are not supposed to work even if the 
__main__.py files are in the right place.

--

___
Python tracker 

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