[issue25843] code_richcompare() don't use constant type when comparing code constants

[STINNER Victor]

STINNER Victor added the comment:

> I will probably remove the optimization on frozenset since it's only useful 
> for AST optimizers (the optimization is a new feature, I considered that it 
> was worth it to add it Python 3.6 as part of my work on the PEP 511).

Hum, it doesn't work: test_compile_ast() of test_compile fails without this 
code. The test relies (indirectly) on the fact that two code objects using a 
frozenset constant are equal.

--

___
Python tracker 

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

Re: Question about how to do something in BeautifulSoup?

[Peter Otten]

inhahe wrote:

> I hope this is an appropriate mailing list for BeautifulSoup questions,
> it's been a long time since I've used python-list and I don't remember if
> third-party modules are on topic. I did try posting to the BeautifulSoup
> mailing list on Google groups, but I've waited a day or two and my message
> hasn't been approved yet.
> 
> Say I have the following HTML (I hope this shows up as plain text here
> rather than formatting):
> 
> "Is today the day?"
> 
> And I want to extract the "Is today the day?" part. There are other places
> in the document with  and , but this is the only place that
> uses color #00, so I want to extract anything that's within a color
> #00 style, even if it's nested multiple levels deep within that.
> 
> - Sometimes the color is defined as RGB(0, 0, 0) and sometimes it's
> defined as #00
> - Sometimes the  is within the  and sometimes the  is
> within the .
> - There may be other discrepancies I haven't noticed yet
> 
> How can I do this in BeautifulSoup (or is this better done in lxml.html)?
> Thanks

I don't see how to do this with a lot of glue code, but it may get you 
started:

def recursive_attr(elem, path):
path = path.split("/")
for name in path:
if elem is None:
break
elem = getattr(elem, name)
return elem

def find(soup):
for outer in soup.find_all(
"span",
style=re.compile(r"color:\s*(RGB\(0,\s*0,\s* 0\)|#00)")):
for inner in [
recursive_attr(outer, "strong/em"),
recursive_attr(outer, "em/strong"),]:
if inner is not None:
yield inner.string

def normalize_ws(s):
return " ".join(s.split())

html = ...
soup = bs4.BeautifulSoup(html)
for match in find(soup):
print(normalize_ws(match))


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

[issue26180] multiprocessing.util._afterfork_registry leak in threaded environment

[Milan Zamazal]

New submission from Milan Zamazal:

When calling multiprocessing.managers.BaseManager repeatedly from a client, 
each time from a new thread, new entry with (already existent) 
multiprocessing.util.ForkAwareLocal instance is inserted as a value into 
multiprocessing.util._afterfork_registry dictionary on each of the calls.  So 
the dictionary grows on each client call and may grow so indefinitely, causing 
memory leak if nothing else.

The attached file demonstrates the problem (Python 2.7 version, it's 
reproducible on 3.4 as well after 2->3 adjustments).  Just run it and look at 
the output.  The printed dictionary contains 10 entries holding the same 
ForkAwareLocal instance although there should be probably just one such entry 
there.

--
components: Library (Lib)
files: bug.py
messages: 258816
nosy: mzamazal
priority: normal
severity: normal
status: open
title: multiprocessing.util._afterfork_registry leak in threaded environment
type: resource usage
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file41690/bug.py

___
Python tracker 

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

Re: one more question on regex

[Vlastimil Brom]

2016-01-22 16:50 GMT+01:00 mg :
> Il Fri, 22 Jan 2016 15:32:57 +, mg ha scritto:
>
>> python 3.4.3
>>
>> import re re.search('(ab){2}','abzzabab')
>> <_sre.SRE_Match object; span=(4, 8), match='abab'>
>>
> re.findall('(ab){2}','abzzabab')
>> ['ab']
>>
>> Why for search() the match is 'abab' and for findall the match is 'ab'?
>
> finditer seems to be consistent with search:
> regex = re.compile('(ab){2}')
>
> for match in regex.finditer('abzzababab'):
>   print ("%s: %s" % (match.start(), match.span() ))
> ...
> 4: (4, 8)
>
> --
> https://mail.python.org/mailman/listinfo/python-list

Hi,
as was already pointed out, findall "collects" the content of the
capturing groups (if present), rather than the whole matching text;

for repeated captures the last content of them is taken discarding the
previous ones; cf.:

>>> re.findall('(?i)(a)x(b)+','axbB')
[('a', 'B')]
>>>
(for multiple capturing groups in the pattern, a tuple of captured
parts are collected)

or with your example with differenciated parts of the string using
upper/lower case:
>>> re.findall('(?i)(ab){2}','aBzzAbAB')
['AB']
>>>

hth,
   vbr
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue20120] Percent-signs (%) in .pypirc should not be interpolated

[Thomas Levine]

Thomas Levine added the comment:

I noticed something else that might be interesting.
If I delete my .pypirc and have setuptools create it,

  python3.5 -c 'import setuptools; setuptools.setup()' register

the .pypirc is created with the un-escaped percent sign and without error.
I receive the error when I try to use the .pypirc next time.

If a different config parser is being used in the writing, perhaps we could at 
least use the same one in both places.

--

___
Python tracker 

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

[issue26183] 2.7.11 won't clean install on Windows 10 x64

[Roger Cook]

New submission from Roger Cook:

The Windows installer stops the installation and backs out on a clean system. 
Here is the relevant section of the log file (msiexec /i 
python-2.7.11.amd64.msi /l*v):

MSI (s) (14:90) [15:13:32:577]: Executing op: ActionStart(Name=RemovePip,,)
Action 15:13:32: RemovePip. 
MSI (s) (14:90) [15:13:32:578]: Executing op: 
CustomActionSchedule(Action=RemovePip,ActionType=3090,Source=C:\Python27\python.exe,Target=-B
 -m ensurepip._uninstall,)
MSI (s) (14:90) [15:13:32:579]: Note: 1: 1721 2: RemovePip 3: 
C:\Python27\python.exe 4: -B -m ensurepip._uninstall 
MSI (s) (14:90) [15:13:32:579]: Note: 1: 2262 2: Error 3: -2147287038 
Error 1721. There is a problem with this Windows Installer package. A program 
required for this install to complete could not be run. Contact your support 
personnel or package vendor. Action: RemovePip, location: 
C:\Python27\python.exe, command: -B -m ensurepip._uninstall 
MSI (s) (14:90) [15:13:37:027]: Note: 1: 2262 2: Error 3: -2147287038 
MSI (s) (14:90) [15:13:37:027]: Product: Python 2.7.10 (64-bit) -- Error 1721. 
There is a problem with this Windows Installer package. A program required for 
this install to complete could not be run. Contact your support personnel or 
package vendor. Action: RemovePip, location: C:\Python27\python.exe, command: 
-B -m ensurepip._uninstall 

Action ended 15:13:37: InstallFinalize. Return value 3.

--- end log ---

It appears that the installer tries to call the Python executable before it has 
been put in place. This fails, and the installer backs out.

Workaround: Install 2.7.10, then install 2.7.11 over it.

--
components: Installation
messages: 258836
nosy: Roger Cook
priority: normal
severity: normal
status: open
title: 2.7.11 won't clean install on Windows 10 x64
type: behavior
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

[issue21949] Document the Py_SIZE() macro.

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
resolution: out of date -> fixed

___
Python tracker 

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

[issue21949] Document the Py_SIZE() macro.

[Roundup Robot]

Roundup Robot added the comment:

New changeset 63183596db79 by Gregory P. Smith in branch '2.7':
Per issue21949 and issue1629: Document the Py_SIZE, Py_TYPE, Py_REFCNT macros.
https://hg.python.org/cpython/rev/63183596db79

--
nosy: +python-dev

___
Python tracker 

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

[issue1629] Py_Size() should be named Py_SIZE()

[Roundup Robot]

Roundup Robot added the comment:

New changeset 63183596db79 by Gregory P. Smith in branch '2.7':
Per issue21949 and issue1629: Document the Py_SIZE, Py_TYPE, Py_REFCNT macros.
https://hg.python.org/cpython/rev/63183596db79

--
nosy: +python-dev

___
Python tracker 

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

[issue26140] inspect.iscoroutinefunction raises TypeError when checks Mock of function or coroutinefunction

[Guido van Rossum]

Guido van Rossum added the comment:

Am I really still needed on this issue?

On Tue, Jan 19, 2016 at 7:46 PM, Hiroyuki Takagi 
wrote:

>
> Hiroyuki Takagi added the comment:
>
> Thank you for reviewing patch.
>
> I wrote test and updated patch. To pass the test, both this patch and
> issue25599's patch are required.
>
> Changes of the patch:
> - copy __code__ not only functions but also methods
> - add autospec (create_autospec) suppoort
>
> I have completely missed about autospec, thank you for a mention about it.
> For autospec, simply copying original __code__ to funcopy makes error on
> existing tests.
> That's why I changed the src of exec, but it seems to be quite ad-hoc. It
> may be better to be improved, but I don't have any good idea, sorry.
>
> On the tests of this patch, I wonder if it's better to use assertIs(..,
> True/False) instead of assertTrue/False, since it was one of the problem in
> issue25599.
> To apply this change and pass test, need to change
> asyncio.iscoroutinefunction to return bool. The change would be very easy,
> just update issue25599's patch like `return_value = bool(getattr(func, ...`.
>
> --
> Added file: http://bugs.python.org/file41664/mock2.patch
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue26182] Deprecation warnings for the future async and await keywords

[Marco Buttu]

New submission from Marco Buttu:

I saw that async and await will become keywords in Python 3.7 :

https://www.python.org/dev/peps/pep-0492/#deprecation-plans

I enabled the deprecation warnings in Python 3.5.1 and Python 3.6 dev, and I 
noticed that assigning to async or await does not issue any deprecation 
warning: 

$ python -Wd -c "import sys; print(sys.version); async = 33"
3.5.1 (default, Jan 21 2016, 19:59:28)
[GCC 4.8.4]

$ python -Wd -c "import sys; print(sys.version); async = 33"
3.6.0a0 (default:4b434a4770a9, Jan 12 2016, 13:01:29)
[GCC 4.8.4]

--
components: Interpreter Core
messages: 258833
nosy: marco.buttu
priority: normal
severity: normal
status: open
title: Deprecation warnings for the future async and await keywords
type: enhancement
versions: 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

[issue26177] tkinter: Canvas().keys returns empty strings.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

split() has many warts, it shouldn't be used. It is enough just call 
splitlist() for elements of a list.

Proposed patch fixes Misc.keys(). It also adds tests for missed options (some 
of them are not explicitly documented).

--
components: +Library (Lib), Tkinter
keywords: +patch
Added file: http://bugs.python.org/file41686/tkinter_keys.patch

___
Python tracker 

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

Re: Refactoring in a large code base

[Marko Rauhamaa]

Rustom Mody :

> On Friday, January 22, 2016 at 1:59:15 PM UTC+5:30, Marko Rauhamaa wrote:
>> I've been there. I think the root problem is to have a code base
>> that's so large and complex.
>
> Bizarre comment... Are you saying large and complex code-bases should
> non-exist?

Why, yes, I am.

>> It *could* be avoided if the engineering director only cared.
>
> Some problems are trivially solvable... for those who have the knowhow
> Some problems are inherently hard but easily detectable as such...
> once again for those who have the knowhow And some are literally (and
> ironically trivially) unsolvable

The knowhow, vision and skill is apparently very rare. On the product
management side, we have the famous case of Steve Jobs, who simply told
the engineers to go back to the drawing boards when he didn't like the
user experience. Most others would have simply surrendered to the
mediocre designs and shipped the product.

We need similar code sanity management. Developers are given much too
much power to mess up the source code. That's why "legacy" is considered
a four-letter word among developers.


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

Re: Refactoring in a large code base

[Rustom Mody]

On Friday, January 22, 2016 at 1:59:15 PM UTC+5:30, Marko Rauhamaa wrote:
> Ben Finney :
> 
> > The author points out there are times when a code base is large and
> > complex enough that refactoring puts the programmer in a state of not
> > knowing whether they're making progress, because until the whole
> > refactoring is complete the errors just cascade and it's hard to tell
> > which ones are relevant.
> 
> I've been there. I think the root problem is to have a code base that's
> so large and complex.

Bizarre comment... Are you saying large and complex code-bases should non-exist?

> 
> It *could* be avoided if the engineering director only cared.

Some problems are trivially solvable... for those who have the knowhow
Some problems are inherently hard but easily detectable as such... once again 
for those who have the knowhow
And some are literally (and ironically trivially) unsolvable

The CS-trinity: 'normal' problems, problems in NP, undecidable problems is a 
classic example of this.
However applying that in real-world practice can be highly non-trivial,
requiring from specialized knowledge to intelligence to genius.

IOW "engineering director does not care" is likely true but also a gross 
oversimplification
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26049] Poor performance when reading large xmlrpc data

[Raimon Esteve]

Changes by Raimon Esteve :


--
nosy: +resteve

___
Python tracker 

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

[issue20120] Percent-signs (%) in .pypirc should not be interpolated

[Jason R. Coombs]

Jason R. Coombs added the comment:

Setuptools 19 has been out for over a month now with no adverse consequences. 
Łukasz and David, as you both originally tagged this as won't fix, how would 
you feel about interpreting this as a defect and regression over Python 2.7 and 
fixing it it all Python 3 versions that receive bug fixes and bringing it into 
parity with Setuptools? If you give me the green light, I'll apply the patches.

--

___
Python tracker 

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

[issue26184] raise an error when create_module() is not defined by exec_module() is for loaders

[Brett Cannon]

New submission from Brett Cannon:

As explained in https://docs.python.org/3/reference/import.html#loaders, as of 
Python 3.6 an error is to be raised when a loader defines exec_module() but not 
create_module(). Probably should raise a TypeError.

--
components: Interpreter Core
messages: 258840
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: raise an error when create_module() is not defined by exec_module() is 
for loaders
type: behavior
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

[issue26169] Pasting 900000 chars into a tk Entry widget fails

[Terry J. Reedy]

Terry J. Reedy added the comment:

I understand now what you were thinking. Even a timeout might not work for this 
because one could paste and within a second click Find-next and likely trigger 
the crash.

I tested printing, copying, and finding 'a'*1 and it worked.  I think this 
is good enough, with probability 1.0, for any real use ;-).

--

___
Python tracker 

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

Re: one more question on regex

[mg]

Il Fri, 22 Jan 2016 21:10:44 +0100, Vlastimil Brom ha scritto:

> 2016-01-22 16:50 GMT+01:00 mg :
>> Il Fri, 22 Jan 2016 15:32:57 +, mg ha scritto:
>>
>>> python 3.4.3
>>>
>>> import re re.search('(ab){2}','abzzabab')
>>> <_sre.SRE_Match object; span=(4, 8), match='abab'>
>>>
>> re.findall('(ab){2}','abzzabab')
>>> ['ab']
>>>
>>> Why for search() the match is 'abab' and for findall the match is
>>> 'ab'?
>>
>> finditer seems to be consistent with search:
>> regex = re.compile('(ab){2}')
>>
>> for match in regex.finditer('abzzababab'):
>>   print ("%s: %s" % (match.start(), match.span() ))
>> ...
>> 4: (4, 8)
>>
>> -- https://mail.python.org/mailman/listinfo/python-list
> 
> Hi,
> as was already pointed out, findall "collects" the content of the
> capturing groups (if present), rather than the whole matching text;
> 
> for repeated captures the last content of them is taken discarding the
> previous ones; cf.:
> 
 re.findall('(?i)(a)x(b)+','axbB')
> [('a', 'B')]

> (for multiple capturing groups in the pattern, a tuple of captured parts
> are collected)
> 
> or with your example with differenciated parts of the string using
> upper/lower case:
 re.findall('(?i)(ab){2}','aBzzAbAB')
> ['AB']


> hth,
>vbr

You explanation of re.findall() results is correct. My point is that the 
documentation states:

re.findall(pattern, string, flags=0)
Return all non-overlapping matches of pattern in string, as a list of 
strings

and this is not what re.findall does. IMHO it should be more reasonable 
to get back the whole matches, since this seems to me the most useful 
information for the user. In any case I'll go with finditer, that returns 
in match object all the infos that anyone can look for.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26177] tkinter: Canvas().keys returns empty strings.

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

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

Re: Refactoring in a large code base

[Marko Rauhamaa]

Ben Finney :

> The author points out there are times when a code base is large and
> complex enough that refactoring puts the programmer in a state of not
> knowing whether they're making progress, because until the whole
> refactoring is complete the errors just cascade and it's hard to tell
> which ones are relevant.

I've been there. I think the root problem is to have a code base that's
so large and complex.

It *could* be avoided if the engineering director only cared.


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

[issue25843] code_richcompare() don't use constant type when comparing code constants

[STINNER Victor]

STINNER Victor added the comment:

I pushed my latest patch with minor changes in comments.

I will wait for buildbots before backporting the change to Python 2.7 and 3.5. 
For the backport, I will probably remove the optimization on frozenset since 
it's only useful for AST optimizers (the optimization is a new feature, I 
considered that it was worth it to add it Python 3.6 as part of my work on the 
PEP 511).

--

___
Python tracker 

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

[issue19883] Integer overflow in zipimport.c

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Synchronized with current sources.

--
components: +Extension Modules
keywords: +needs review
nosy: +benjamin.peterson
versions:  -Python 3.4
Added file: http://bugs.python.org/file41687/zipimport_int_overflow_3.patch

___
Python tracker 

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

PyDev 4.5.3 Released

[Fabio Zadrozny]

Release Highlights:
---

* Debugger

* Fixed issue in set next statement (#PyDev 651).

* pydevd.settrace was stopping inside the debugger and not in user code
(#PyDev 648).

* subprocess.Popen could crash when running non python executable (#PyDev
650).

* PyUnit view

* The last pinned test suite appears as the first entry in the history.

* More information is shown on the test run history.

* A string representation of the test suite can be saved in the clipboard
(last item in the test run history).

* Indexing: fixed issue where the indexing and code-analysis could race
with each other and one could become corrupt.


What is PyDev?
---

PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and
IronPython development.

It comes with goodies such as code completion, syntax highlighting, syntax
analysis, code analysis, refactor, debug, interactive console, etc.

Details on PyDev: http://pydev.org
Details on its development: http://pydev.blogspot.com


What is LiClipse?
---

LiClipse is a PyDev standalone with goodies such as support for Multiple
cursors, theming, TextMate bundles and a number of other languages such as
Django Templates, Jinja2, Kivy Language, Mako Templates, Html, Javascript,
etc.

It's also a commercial counterpart which helps supporting the development
of PyDev.

Details on LiClipse: http://www.liclipse.com/



Cheers,

--
Fabio Zadrozny
--
Software Developer

LiClipse
http://www.liclipse.com

PyDev - Python Development Environment for Eclipse
http://pydev.org
http://pydev.blogspot.com

PyVmMonitor - Python Profiler
http://www.pyvmmonitor.com/
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue19225] lack of PyExc_BufferError doc

[Gedai Tamás Bence]

Gedai Tamás Bence added the comment:

I've created a new table for warnings and added the missing exceptions to the 
exceptions table.

I did not find a link for VMSError, but I added it to the table.

Note that the exceptions table is not absolutely in alphabetical order, I can 
fix it as well, if it's needed.

--
keywords: +patch
Added file: http://bugs.python.org/file41688/doc_exceptions.patch

___
Python tracker 

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

Deprecation warnings for the future async and await keywords

[Marco Buttu]

I enabled the deprecation warnings in Python 3.5.1 and Python 3.6 dev, 
and I noticed that assigning to async or await does not issue any 
deprecation warning:


$ python -Wd -c "import sys; print(sys.version); async = 33"
3.5.1 (default, Jan 21 2016, 19:59:28)
[GCC 4.8.4]
$ python -Wd -c "import sys; print(sys.version); async = 33"
3.6.0a0 (default:4b434a4770a9, Jan 12 2016, 13:01:29)
[GCC 4.8.4]


Is it normal?
--
Marco Buttu
--
https://mail.python.org/mailman/listinfo/python-list

[issue26099] site ignores ImportError when running sitecustomize and usercustomize

[STINNER Victor]

STINNER Victor added the comment:

Brett: "Semantics are fine (I initially misread what you wanted to do; sorry)."

Ok, I pushed my change.

Brett: "And I wouldn't backport since it's an enhancement and not a bugfix."

Ok, fine.

--
resolution:  -> fixed
status: open -> closed
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

[issue26099] site ignores ImportError when running sitecustomize and usercustomize

[Roundup Robot]

Roundup Robot added the comment:

New changeset c873a479a6a3 by Victor Stinner in branch 'default':
site: error on sitecustomize import error
https://hg.python.org/cpython/rev/c873a479a6a3

--
nosy: +python-dev

___
Python tracker 

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

[issue26169] Pasting 900000 chars into a tk Entry widget fails

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I want to say that may be we can make a workaround for this issue in IDLE if it 
is worth. The "wont fix" resolution looks reasonable to me, but this doesn't 
mean that the issue couldn't be solved in principle (though the solution can be 
very costly). I'm closing this issue, but only because we have too  much other 
open IDLE issues, and with very good chance this issue will never solved.

Other issue is that it would be nice to make IDLE and Tkinter more responsive. 
Allow to interrupt long-running Tk operation and ask the user to save his files 
before quit. But this is separate issue.

--
resolution:  -> wont fix
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

Re: Refactoring in a large code base

[Chris Angelico]

On Fri, Jan 22, 2016 at 10:54 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa  wrote:
>> So what do you do with a huge program?
>
> Modularize. Treat each module as a separate product with its own release
> cycle, documentation, apis, ownership etc.
>
> What is a reasonable size of a module? It is something you would
> consider replacing with a new implementation with a moderate effort
> (say, in a single quarter).
>
>> CPython is a large and complex program. How do you propose doing it
>> "right"?
>
> I don't know CPython specifically to give solid recommendations, but I
> would imagine the core language engine should be in a repository
> separate from the standard library, and most standard library modules
> should be in their respective repositories and have their individual
> internal release cycles.
>
> A CPython release would then weave the package together from the
> components that were previously (internally) released.

Okay. So let's suppose we strip out huge slabs of the standard library
and make an absolutely minimal "base library", with an "extended
library" that can run on its own separate release cycle. (This has
already been discussed; the biggest problems with the idea aren't
technical, but logistical - not just for the Python devs but for
everyone who has to get approval for software upgrades.) Let's suppose
the base library consists of just the modules necessary for a basic
invocation:

rosuav@sikorsky:~$ python3 -c 'import sys; print(sorted(sys.modules.keys()))'
['__main__', '_codecs', '_collections_abc', '_frozen_importlib',
'_frozen_importlib_external', '_imp', '_io', '_signal',
'_sitebuiltins', '_stat', '_sysconfigdata', '_thread', '_warnings',
'_weakref', '_weakrefset', 'abc', 'builtins', 'codecs', 'encodings',
'encodings.aliases', 'encodings.latin_1', 'encodings.utf_8', 'errno',
'genericpath', 'io', 'marshal', 'os', 'os.path', 'posix', 'posixpath',
'site', 'stat', 'sys', 'sysconfig', 'zipimport']

Alright. Can you rewrite all of those modules in three months? Not
even digging into the language itself, just the base library. This is
the bare minimum to get a viable Python execution environment going
(you might be able to cut it down a bit, but not much), so it can't be
modularized into separate projects.

And then there's the language itself. The cpython/Python directory has
58 .c files, many of which are closely tied to each other. The
cpython/Objects directory has another 39, representing specific object
types (bytes, tuple, range, method) that are implemented in C. And
cpython/Parser has 17 more just to handle the language parser. Edits
often affect multiple files and must be kept in sync. How would you
modularize that out? Which part would you spin off as a separate
project with its own release cycle? The garbage collector? The string
object? The peephole optimizer? The import machinery? Each of these is
already too big to rewrite in three months, plus they're fairly
tightly linked to all the other modules. All that code represents the
accumulation of hundreds of thousands of fixes to prevent tens of
millions of bugs (some of which will be visible on bugs.python.org,
but most would have been found and prevented during early testing);
throwing the code away means throwing all that away.

http://www.joelonsoftware.com/articles/fog69.html

I don't agree with everything Joel says, but seriously, do not waste
your time with a full rewrite - even in theory. And I can say this
from hard experience on both sides. I have an active project for a MUD
server, which was originally deployed as a byte-oriented service (it
took ASCII-compatible bytes from clients and sent those same octets
out to other clients). When I decided that the server should work with
Unicode text internally (expecting and transmitting UTF-8), I kept on
coming across stupid problems where the code had been written with
faulty assumptions, and I had to keep on fixing those. Would it have
been better to throw the code away and start over? Well, let me tell
you, it would certainly have made the Unicode handling a lot easier,
so if you're looking at starting your own project, make sure you learn
from my hassles and bake in Unicode support from the start! But that
would have meant throwing away all the bugfixes for all the bugs that
I'd noticed across the years, such as:

1) On login, typing "quit" when prompted for a user name or password
would log you out. The "passwd" (change password) command had to also
prevent you from *setting* your password to "quit", because that would
effectively lock your account against login.

2) Some clients send backspace as 08; others send FF; some send 08 20
08. Cope with them all.

3) If a bug prevents the admin account from working, there needs to be
a way to diagnose and fix that code using shell access to the back-end
server, without needing the actual admin account.

Re: Refactoring in a large code base

[Thomas Mellman]

On Fri, 22 Jan 2016 04:04:44 -0800, Rustom Mody wrote:

> These are just specific examples that I am familiar with Chris' general
> point still stands, viz take the large and complex program that is
> cpython and clean up these messinesses: You will still have a large and
> complex program

I'm not really sure what the point is we're working on...  let me
propose these:

- unix principle is good: keep things simple, limited in scope.
  Then leverage that.

- there will always be complexity, but if the complexity is
  modularized, it's controlled.

  In particular, the complexity of a program should represent the
  complexity of the problem.  I call that "structural complexity".
  To be avoided, corrected, is "superficial complexity",
  where the complexity of a system is squished into a single (or
  reduced number of) planes.  Like vomiting a program onto a desk.

- "Advice" that the program needs to be refracted is generally not helpful.

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

Re: Refactoring in a large code base

[Chris Angelico]

On Fri, Jan 22, 2016 at 11:04 PM, Rustom Mody  wrote:
> On Friday, January 22, 2016 at 4:49:19 PM UTC+5:30, Chris Angelico wrote:
>> On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa  wrote:
>> > The knowhow, vision and skill is apparently very rare. On the product
>> > management side, we have the famous case of Steve Jobs, who simply told
>> > the engineers to go back to the drawing boards when he didn't like the
>> > user experience. Most others would have simply surrendered to the
>> > mediocre designs and shipped the product.
>> >
>> > We need similar code sanity management. Developers are given much too
>> > much power to mess up the source code. That's why "legacy" is considered
>> > a four-letter word among developers.
>>
>> So what do you do with a huge program? Do you send it back to the
>> developers and say "Do this is less lines of code"?
>>
>> CPython is a large and complex program. How do you propose doing it "right"?
>
> Put thus 'generistically' this is a rhetorical question and makes Marko look 
> like
> he's making a really foolish point
>
> Specifically, what little Ive seen under the CPython hood looked distinctly 
> improvable. egs.
>
> 1. My suggestion to have the docs re. generator-function vs generator-objects
> cleaned up had no takers
> 2. My students trying to work inside the lexer made a mess because the extant 
> lexer is a mess.
> I.e. while python(3) *claims* to accept Unicode input, the actual lexer is
> an ASCII lexer special-cased for unicode rather than pre-lexing utf8 to 
> unicode
>
> These are just specific examples that I am familiar with

Yes, there are some parts of CPython that can be improved. That's true
of every large project (it's said that every program has at least one
bug and could be shortened by at least one instruction, from which it
can be deduced that every program can be reduced to a single
instruction that doesn't work).

Regarding lexers specifically, I have never seen any full-size
language parser that I've wanted to tinker with. They're always highly
optimized pieces of code, dealing with innumerable edge and corner
cases, and exploring them is always like dipping my toe into something
that's either ice-cold water or highly caustic acid, and I can't tell
which.

> Chris' general point still stands, viz take the large and complex program 
> that is cpython
> and clean up these messinesses: You will still have a large and complex 
> program

Right. You could definitely spin off *some* of CPython into a separate
project (flip through the standard library - quite a few of those
modules, if proposed for stdlib inclusion today, would be denied
"better on PyPI"), but my point isn't that it can't be improved, but
that there's an irreducible complexity to it that exceeds the "rewrite
in a quarter" mark by a huge margin.

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

Re: Refactoring in a large code base

[Chris Angelico]

On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa  wrote:
> The knowhow, vision and skill is apparently very rare. On the product
> management side, we have the famous case of Steve Jobs, who simply told
> the engineers to go back to the drawing boards when he didn't like the
> user experience. Most others would have simply surrendered to the
> mediocre designs and shipped the product.
>
> We need similar code sanity management. Developers are given much too
> much power to mess up the source code. That's why "legacy" is considered
> a four-letter word among developers.

So what do you do with a huge program? Do you send it back to the
developers and say "Do this is less lines of code"?

CPython is a large and complex program. How do you propose doing it "right"?

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

[issue25843] code_richcompare() don't use constant type when comparing code constants

[Roundup Robot]

Roundup Robot added the comment:

New changeset 6c33d4cc9b8f by Victor Stinner in branch 'default':
code_richcompare() now uses the constants types
https://hg.python.org/cpython/rev/6c33d4cc9b8f

--
nosy: +python-dev

___
Python tracker 

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

Re: Refactoring in a large code base

[Charles T. Smith]

On Fri, 22 Jan 2016 12:19:50 +0200, Marko Rauhamaa wrote:

> We need similar code sanity management. Developers are given much too
> much power to mess up the source code. That's why "legacy" is considered
> a four-letter word among developers.

When I started in this business, in the mid-70s, there was the prospect
of my working under a "programmer-analyst" - there was, then, a whole
hierarchy of programmers.  I resisted that bitterly and was "lucky"
enough to be at the forefront of changes - I would be able to avoid that
until the concept was dead.

Now, 40 years later ... it seems like a good idea to me ... but more
dead than it's ever been and getting deader all the time.

Part of the problem is that the whole profession is dead - now the
people doing the programming are the application experts, and just
programmers are considered at the level that we used to consider
"operators" were at   :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Refactoring in a large code base

[Marko Rauhamaa]

Chris Angelico :

> On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa  wrote:
> So what do you do with a huge program?

Modularize. Treat each module as a separate product with its own release
cycle, documentation, apis, ownership etc.

What is a reasonable size of a module? It is something you would
consider replacing with a new implementation with a moderate effort
(say, in a single quarter).

> CPython is a large and complex program. How do you propose doing it
> "right"?

I don't know CPython specifically to give solid recommendations, but I
would imagine the core language engine should be in a repository
separate from the standard library, and most standard library modules
should be in their respective repositories and have their individual
internal release cycles.

A CPython release would then weave the package together from the
components that were previously (internally) released.


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

Re: Refactoring in a large code base

[Rustom Mody]

On Friday, January 22, 2016 at 4:49:19 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa  wrote:
> > The knowhow, vision and skill is apparently very rare. On the product
> > management side, we have the famous case of Steve Jobs, who simply told
> > the engineers to go back to the drawing boards when he didn't like the
> > user experience. Most others would have simply surrendered to the
> > mediocre designs and shipped the product.
> >
> > We need similar code sanity management. Developers are given much too
> > much power to mess up the source code. That's why "legacy" is considered
> > a four-letter word among developers.
> 
> So what do you do with a huge program? Do you send it back to the
> developers and say "Do this is less lines of code"?
> 
> CPython is a large and complex program. How do you propose doing it "right"?

Put thus 'generistically' this is a rhetorical question and makes Marko look 
like
he's making a really foolish point

Specifically, what little Ive seen under the CPython hood looked distinctly 
improvable. egs.

1. My suggestion to have the docs re. generator-function vs generator-objects
cleaned up had no takers
2. My students trying to work inside the lexer made a mess because the extant 
lexer is a mess.
I.e. while python(3) *claims* to accept Unicode input, the actual lexer is
an ASCII lexer special-cased for unicode rather than pre-lexing utf8 to unicode

These are just specific examples that I am familiar with
Chris' general point still stands, viz take the large and complex program that 
is cpython
and clean up these messinesses: You will still have a large and complex program
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Refactoring in a large code base

[Marko Rauhamaa]

Rustom Mody :

> These are just specific examples that I am familiar with Chris'
> general point still stands, viz take the large and complex program
> that is cpython and clean up these messinesses: You will still have a
> large and complex program

No, as long as the ugly parts are compartmentalized, you have a better
chance at refactoring them -- or replacing them altogether.

Modularization is an obvious, but under-practiced, method of managing
complexity.


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

[issue26146] PEP 511: Add ast.Constant to allow AST optimizer to emit constants

[STINNER Victor]

STINNER Victor added the comment:

Patch version 2:

- rework the whole patch
- add unit tests
- fix AST validation: the code was completly wrong in patch 1, I don't 
understand how it worked :-p Validate also correctly nested tuple and nested 
frozenset.
- add a comment to explain why obj2ast_constant() doesn't have to Py_INCREF() 
singletons
- handle also Ellipsis
- revert changes on set_context(). It seems like set_context() is only called 
with code emited directly by the compiler (not by compile(custom_ast_tree, 
...)). If someone finds a way to call set_context() with an ast.Constant, we 
can support this case later.

--
Added file: http://bugs.python.org/file41689/constant-2.patch

___
Python tracker 

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

Re: Refactoring in a large code base

[Marko Rauhamaa]

Chris Angelico :

> Alright. Can you rewrite all of those modules in three months?

The point is not to rewrite modules except as a fallback for a
hopelessly badly written module.

> And then there's the language itself. The cpython/Python directory has
> 58 .c files, many of which are closely tied to each other.

Putting modularization in place after the spaghetti has been created is
very hard. It can be done, though, and good things come out of the
effort.

> I don't agree with everything Joel says, but seriously, do not waste
> your time with a full rewrite - even in theory. And I can say this
> from hard experience on both sides.

As long as you are happy with your code base, you don't have to change
everything just for an abstract principle.

However, as a matter of rule, older code bases have been bloated till
they can barely be maintained. That's when the management starts to
listen to new ideas. Better late than never.

> Would it have been better to throw the code away and start over?

Again, modularization doesn't entail rewriting -- it simply makes
localized rewriting a practical option for desperate situations.

> So how can you rewrite *any* large project in three months?

Let go of the rewriting already.


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

[issue18018] SystemError: Parent module '' not loaded, cannot perform relative import

[Brett Cannon]

Brett Cannon added the comment:

Thanks to everyone for providing feedback. I went with ImportError in the end 
as that's what the pure Python implementation of __import__() already raised.

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

[issue26128] Let the subprocess.STARTUPINFO constructor take arguments

[Terry J. Reedy]

Terry J. Reedy added the comment:

STARTUPINFO is a class whose instances have 5 attributes.  Being able to set 
attributes on creation is pretty normal.  If one can optionally be set in 
__init__, same should be true for all.  I would recommend that params be 
keyword-only.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue26128] Let the subprocess.STARTUPINFO constructor take arguments

[Ram Rachum]

Ram Rachum added the comment:

Agreed on keywords-only.

--

___
Python tracker 

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

[issue18018] SystemError: Parent module '' not loaded, cannot perform relative import

[Roundup Robot]

Roundup Robot added the comment:

New changeset c4e4886c6052 by Brett Cannon in branch 'default':
Issue #18018: Raise an ImportError if a relative import is attempted
https://hg.python.org/cpython/rev/c4e4886c6052

--
nosy: +python-dev

___
Python tracker 

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

[issue25791] Raise an ImportWarning when __spec__.parent/__package__ isn't defined for a relative import

[Roundup Robot]

Roundup Robot added the comment:

New changeset 219c44fe8968 by Brett Cannon in branch 'default':
Issue #25791: Warn when __package__ != __spec__.parent.
https://hg.python.org/cpython/rev/219c44fe8968

--

___
Python tracker 

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

[issue21762] update the import machinery to only use __spec__

[Brett Cannon]

Brett Cannon added the comment:

I think that leaves the following attributes to be updated/checked for 
dependencies in importlib (and if they are found, raise ImportWarning when they 
differ):

1. __path__
2. __loader__
3. __file__
4. __cached__

--

___
Python tracker 

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

[issue26095] Update porting HOWTO to special-case Python 2 code, not Python 3

[Brett Cannon]

Changes by Brett Cannon :


--
assignee: docs@python -> brett.cannon

___
Python tracker 

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

[issue25234] test_eintr.test_os_open hangs under Xcode 7

[Roundup Robot]

Roundup Robot added the comment:

New changeset 9d65a195246b by Brett Cannon in branch 'default':
Issue #25234: Skip test_eintr.test_open() under OS X to avoid hanging
https://hg.python.org/cpython/rev/9d65a195246b

--

___
Python tracker 

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

[issue25234] test_eintr.test_os_open hangs under Xcode 7

[Brett Cannon]

Changes by Brett Cannon :


--
status: open -> closed

___
Python tracker 

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

[issue26149] Suggest PyCharm Community as an editor for Unix platforms

[Terry J. Reedy]

Terry J. Reedy added the comment:

Berker, I agree with you.  The doc section is woefully incomplete and 
unix-specific.  It probably dates back to when Python only ran on unix.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0

[Zachary Ware]

Zachary Ware added the comment:

Here's a patch that specifies /fp:strict if it looks like ICC is being used for 
the build.  It also adds a convenient property for checking whether it's an ICC 
build ($(ICCBuild)).  This doesn't change anything for MSVC builds but allows 
ICC builds to pass test_math, test_cmath, test_audioop, etc.; as such, it 
should be applied to all three branches.

As far as replacing the non-constants that MSVC doesn't like, I'm +1 but not 
too bothered about it.  I'm happy to test if anyone supplies a patch for it.

--
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org/file41696/issue25934.diff

___
Python tracker 

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

Re: one more question on regex

[mg]

Il Fri, 22 Jan 2016 15:32:57 +, mg ha scritto:

> python 3.4.3
> 
> import re re.search('(ab){2}','abzzabab')
> <_sre.SRE_Match object; span=(4, 8), match='abab'>
> 
 re.findall('(ab){2}','abzzabab')
> ['ab']
> 
> Why for search() the match is 'abab' and for findall the match is 'ab'?

finditer seems to be consistent with search:
regex = re.compile('(ab){2}')

for match in regex.finditer('abzzababab'): 
  print ("%s: %s" % (match.start(), match.span() ))
... 
4: (4, 8)

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

Re: Deprecation warnings for the future async and await keywords

[Ian Kelly]

On Fri, Jan 22, 2016 at 4:12 AM, Marco Buttu  wrote:
> I enabled the deprecation warnings in Python 3.5.1 and Python 3.6 dev, and I
> noticed that assigning to async or await does not issue any deprecation
> warning:
>
> $ python -Wd -c "import sys; print(sys.version); async = 33"
> 3.5.1 (default, Jan 21 2016, 19:59:28)
> [GCC 4.8.4]
> $ python -Wd -c "import sys; print(sys.version); async = 33"
> 3.6.0a0 (default:4b434a4770a9, Jan 12 2016, 13:01:29)
> [GCC 4.8.4]
>
>
> Is it normal?

They're not reserved words, see
https://www.python.org/dev/peps/pep-0492/#transition-plan
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +yselivanov

___
Python tracker 

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

[issue25907] Documentation i18n: Added trans tags in sphinx templates

[Roundup Robot]

Roundup Robot added the comment:

New changeset b1615165fa4a by Victor Stinner in branch '3.5':
doc: i18n HTML templates
https://hg.python.org/cpython/rev/b1615165fa4a

New changeset 5af5b36c197e by Victor Stinner in branch 'default':
Merge 3.5 (i18n doc, issue #25907)
https://hg.python.org/cpython/rev/5af5b36c197e

--
nosy: +python-dev

___
Python tracker 

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

[issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)

[STINNER Victor]

STINNER Victor added the comment:

as i expected, the bug disappeared. I'm not interested to investigate a random 
failure which only occurred once. I close the issue.

--
resolution:  -> out of date
status: open -> closed

___
Python tracker 

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

[issue25907] Documentation i18n: Added trans tags in sphinx templates

[STINNER Victor]

STINNER Victor added the comment:

I applied 3 patches to branches 3.5 and default (3.6), but the patches don't 
apply cleanly to Python 2.7.

Can you please cook patches for Python 2.7?

(I suggest to focus on translation of the Python 3 documentation, but for me, 
it's cheap to apply such patch to Python 2.7.)

--
versions: +Python 2.7, Python 3.5, 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

[issue26164] test_with_pip() of test_venv fails on Windows buildbots

[STINNER Victor]

STINNER Victor added the comment:

It looks like the issue was fixed with the upgrade of pip to 8.0.2: changeset 
c75802aaa4de (merge into default: changeset ca78f5e41012).

--

___
Python tracker 

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

[issue26161] Use Py_uintptr_t instead of void* for atomic pointers

[Roundup Robot]

Roundup Robot added the comment:

New changeset ff68ffcc6244 by Victor Stinner in branch 'default':
Use Py_uintptr_t for atomic pointers
https://hg.python.org/cpython/rev/ff68ffcc6244

--
nosy: +python-dev

___
Python tracker 

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

[issue26161] Use Py_uintptr_t instead of void* for atomic pointers

[STINNER Victor]

Changes by STINNER Victor :


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

Re: Refactoring in a large code base

[Chris Angelico]

On Sat, Jan 23, 2016 at 12:00 AM, Marko Rauhamaa  wrote:
> However, as a matter of rule, older code bases have been bloated till
> they can barely be maintained. That's when the management starts to
> listen to new ideas. Better late than never.

Okay. Start persuading "management" (presumably the PSU) that CPython
needs to be more modular, with different release cycles for different
components. Your first step is to figure out the boundaries between
those components. Get started.

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

[issue26178] Python C-API: __all__ Creator

[Devyn Johnson]

New submission from Devyn Johnson:

When creating Python modules via th C-API, it would be wonderful if there were 
an easier and more efficient way of creating an "__all__" for the module. In my 
opinion, an API function should be made; i.e., something like PyALL("FUNC1", 
"FUNC2", ...)


Currently, I use something like the below code.

"""
PyObject *create_all(void);

PyObject *create_all(void) {  // Create __all__
#define _ALLSTRING "[ss"
#define _ENDSTRING "]"
return Py_BuildValue(
_ALLSTRING
#if defined(ENV64BIT) && (defined(__x86_64__) || defined(__x86_64))
"sss"
#ifdef __BMI2__
""
#endif
#endif
_ENDSTRING,
// STRING CONVERSIONS
"lowercasestr",
"uppercasestr",
// FIND AND REPLACE/REMOVE
"strreplace",
"strreplace_once",
"rmgravequote",
// ASSEMBLY-RELATED COMMANDS
#if defined(ENV64BIT) && (defined(__x86_64__) || defined(__x86_64))
"rdtsc",
"get_vendor_id",
"get_cpu_stepping",
#ifdef __BMI2__
"is_fpu_aval",
"is_avx_aval",
"is_fma_aval",
"is_aes_aval",
#endif
#endif
"nop"
);
}

// Some code excluded

MODINIT {  // Initialize module
PyObject *m;
m = PyModule_Create();
PyModule_AddObject(m, "__all__", create_all());
PyModule_AddStringConstant(m, "__author__", __author__);
PyModule_AddStringConstant(m, "__version__", __version__);
if (m == NULL)
return NULL;
return m;
}
"""

--
components: Interpreter Core
messages: 258804
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: Python C-API: __all__ Creator
type: enhancement
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

[issue25876] test_gdb: use subprocess._args_from_interpreter_flags() to test Python with more options

[STINNER Victor]

Changes by STINNER Victor :


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

Re: Refactoring in a large code base

[Marko Rauhamaa]

Rustom Mody :

> IOW anyone who thinks that *arbitrary* complexity can *always* be
> tamed either has a visa to utopia or needs to re-evaluate (or get) a
> CS degree

Not all complexity can be tamed, but what you can't tame you shouldn't
release, either.


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

Re: Refactoring in a large code base

[Marko Rauhamaa]

Chris Angelico :

> Okay. Start persuading "management" (presumably the PSU) that CPython
> needs to be more modular, with different release cycles for different
> components. Your first step is to figure out the boundaries between
> those components. Get started.

Gladly, I don't need to do anything about CPython. This particular
strawman was erected by you:

> CPython is a large and complex program. How do you propose doing it
> "right"?

It's up to you to take my proposal or ignore it.

However, I have had my share of windmills to battle; I'm happy to say
I've managed to bring down a few of them!


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

Re: Refactoring in a large code base

[Rustom Mody]

On Friday, January 22, 2016 at 7:13:49 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
> 
> > IOW anyone who thinks that *arbitrary* complexity can *always* be
> > tamed either has a visa to utopia or needs to re-evaluate (or get) a
> > CS degree
> 
> Not all complexity can be tamed, but what you can't tame you shouldn't
> release, either.

And how do you propose to legislate that?
If you leave it to the wetware (untamed!) boxes atop our shoulders will not
two developers have wildly different complexity thresholds?

And as soon as you suggest an objective (∴ algorithmic) solution to detecting 
complexity you have landed with the halting problem (or more precisely Rice 
theorem)

tl;dr The HP is amazingly deceptive and you just got tripped by it

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

[issue26178] Python C-API: __all__ Creator

[Devyn Johnson]

Devyn Johnson added the comment:

Thanks, @skrah and @haypo . I never thought of it that way. I made "__all__" in 
my extensions because "__all__" was used in many Python scripts. Thanks for the 
alternative perspective.

--
status: open -> closed

___
Python tracker 

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

[issue25876] test_gdb: use subprocess._args_from_interpreter_flags() to test Python with more options

[Roundup Robot]

Roundup Robot added the comment:

New changeset 9faa15da2dde by Victor Stinner in branch 'default':
Issue #25876: Fix also test_set() of test_gdb when -E command line is used
https://hg.python.org/cpython/rev/9faa15da2dde

--

___
Python tracker 

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

[issue26108] Calling PyInitialize with 2.7.11 on Windows x64 terminates process

[Eryk Sun]

Changes by Eryk Sun :


--
stage:  -> resolved

___
Python tracker 

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

Re: Refactoring in a large code base

[Chris Angelico]

On Sat, Jan 23, 2016 at 12:48 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> Okay. Start persuading "management" (presumably the PSU) that CPython
>> needs to be more modular, with different release cycles for different
>> components. Your first step is to figure out the boundaries between
>> those components. Get started.
>
> Gladly, I don't need to do anything about CPython. This particular
> strawman was erected by you:
>
>> CPython is a large and complex program. How do you propose doing it
>> "right"?
>
> It's up to you to take my proposal or ignore it.
>
> However, I have had my share of windmills to battle; I'm happy to say
> I've managed to bring down a few of them!

Okay. You have fun releasing nothing that you aren't confident can fit
within your definitions (and by the way, you were the one who brought
up the three-month rewrite, not me); I'm going to keep on following
the principle that "practicality beats purity", and release actual
working code.

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

Re: How clean/elegant is Python's syntax?

[Rustom Mody]

On Friday, May 31, 2013 at 1:06:29 AM UTC+5:30, Steven D'Aprano wrote:
> On Thu, 30 May 2013 10:12:22 -0700, rusi wrote:
> 
> > On Thu, May 30, 2013 at 9:34 AM, Ma Xiaojun wrote:
> 
> >> Wait a minute! Isn't the most nature way of doing/thinking "generating
> >> 9x9 multiplication table" two nested loop?
> > 
> > Thats like saying that the most natur(al) way of using a car is to
> > attach a horse to it.
> >[...]
> > Likewise in the world of programming, 90% of programmers think
> > imperative/OO programming is natural while functional programming is
> > strange.  Just wait 10 years and see if things are not drastically
> > different!
> 
> It won't be. Functional programming goes back to Lisp, which is nearly as 
> old as Fortran and older than Cobol. There have been many decades for 
> functional languages to become mainstream, but they've never quite done 
> it. There's no reason to think that the next decade will see a change to 
> this.

Interesting point...
With interesting (counter)examples: 
http://blog.languager.org/2016/01/how-long.html

[With apologies for necroposting]
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue25876] test_gdb: use subprocess._args_from_interpreter_flags() to test Python with more options

[Roundup Robot]

Roundup Robot added the comment:

New changeset 05ea3efadead by Victor Stinner in branch 'default':
Issue #25876: test_gdb: use subprocess._args_from_interpreter_flags() to test
https://hg.python.org/cpython/rev/05ea3efadead

--
nosy: +python-dev

___
Python tracker 

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

Re: Refactoring in a large code base

[Rustom Mody]

On Friday, January 22, 2016 at 6:05:02 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Jan 22, 2016 at 11:04 PM, Rustom Mody  wrote:
> > 2. My students trying to work inside the lexer made a mess because the 
> > extant lexer is a mess.
> > I.e. while python(3) *claims* to accept Unicode input, the actual lexer is
> > an ASCII lexer special-cased for unicode rather than pre-lexing utf8 to 
> > unicode
> >
> > These are just specific examples that I am familiar with
> 
> 
> Regarding lexers specifically, I have never seen any full-size
> language parser that I've wanted to tinker with. They're always highly
> optimized pieces of code, dealing with innumerable edge and corner
> cases, and exploring them is always like dipping my toe into something
> that's either ice-cold water or highly caustic acid, and I can't tell
> which.
> 

You just gave a graphic vivid description...
of the same thing Marko is describing: ;-) viz.
A full-size language parser is something that you - an experienced developer -
make a point of avoiding.
So then the question comes down to this: Is this the order of nature?
Or is it man-made disorder?
Jury's out on that one for lexers/parsers specifically.
For arbitrary code in general, the problem that it may be arbitrarily and 
unboundedly 
complex/complicated is the oldest problem in computer science: the halting 
problem.

IOW anyone who thinks that *arbitrary* complexity can *always* be tamed either
has a visa to utopia or needs to re-evaluate (or get) a CS degree
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26178] Python C-API: __all__ Creator

[STINNER Victor]

STINNER Victor added the comment:

Seting __all__ is usually need to exclude some symbols from "from module import 
*". In Python, it's common to write public or private (name prefixed by "_") 
helper functions which are excluded from __all__. In C extensions, you have to 
explicitly expose a function. Why would you expose a function but exclude it 
from __all__?

--
nosy: +haypo

___
Python tracker 

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

[issue26178] Python C-API: __all__ Creator

[Stefan Krah]

Stefan Krah added the comment:

I agree, and that's pretty much what Guido said here, too:

https://mail.python.org/pipermail/python-dev/2001-February/012591.html

--
nosy: +skrah

___
Python tracker 

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

[issue26164] test_with_pip() of test_venv fails on Windows buildbots

[Donald Stufft]

Donald Stufft added the comment:

Yes, it should have been. Sorry forgot this issue was opened.

--

___
Python tracker 

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

[issue26164] test_with_pip() of test_venv fails on Windows buildbots

[STINNER Victor]

Changes by STINNER Victor :


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

[issue26108] Calling PyInitialize with 2.7.11 on Windows x64 terminates process

[Eryk Sun]

Changes by Eryk Sun :


--
resolution: not a bug -> duplicate
superseder:  -> 32-bit 2.7.11 installer creates registry keys that are 
incompatible with the installed python27.dll

___
Python tracker 

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

Question about how to do something in BeautifulSoup?

[inhahe]

I hope this is an appropriate mailing list for BeautifulSoup questions,
it's been a long time since I've used python-list and I don't remember if
third-party modules are on topic. I did try posting to the BeautifulSoup
mailing list on Google groups, but I've waited a day or two and my message
hasn't been approved yet.

Say I have the following HTML (I hope this shows up as plain text here
rather than formatting):

"Is
today the day?"

And I want to extract the "Is today the day?" part. There are other places
in the document with  and , but this is the only place that
uses color #00, so I want to extract anything that's within a color
#00 style, even if it's nested multiple levels deep within that.

- Sometimes the color is defined as RGB(0, 0, 0) and sometimes it's defined
as #00
- Sometimes the  is within the  and sometimes the  is
within the .
- There may be other discrepancies I haven't noticed yet

How can I do this in BeautifulSoup (or is this better done in lxml.html)?
Thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26179] Python C-API "unused-parameter" warnings

[Devyn Johnson]

New submission from Devyn Johnson:

When compiling Python C-API extensions with "-Wextra", warnings like 

warning: unused parameter ‘self’ [-Wunused-parameter]

appear for code (like below). It seems like a minor issue for a warning to 
appear when "PyObject *self, PyObject *args" is required. Is there an 
underlying issue in the API?

static PyObject *mathfunc_ismersenneprime(PyObject *self, PyObject *args) {
sllint num;
ASSERT_LONGLONG_ARG(num);
if (num < (sllint)0) ERR_POSITIVE_INT;
returnbool(islonglongmersenneprime(num));
}

--
components: Interpreter Core
messages: 258809
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: Python C-API "unused-parameter" warnings
type: behavior
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: Refactoring in a large code base

[Chris Angelico]

On Sat, Jan 23, 2016 at 12:30 AM, Rustom Mody  wrote:
> You just gave a graphic vivid description...
> of the same thing Marko is describing: ;-) viz.
> A full-size language parser is something that you - an experienced developer -
> make a point of avoiding.

It's worth noting that "experienced developer" covers a huge range of
skills. There are quite a few other areas that I do not tinker with
(crypto, CPU-level optimizations, and such), not because they're
impossible to understand, but because *I* have not the skill to
understand and improve them. This does mean they're complicated
(they're beyond the "one weekend of tinkering" barrier that any
serious geek should be able to invest), but I'm sure there are
language nerds out there who are so familiar with the grammar of
 that they'll pick up CPython's grammar and make
a change with confidence that it'll do what they expect.

> So then the question comes down to this: Is this the order of nature?
> Or is it man-made disorder?
> Jury's out on that one for lexers/parsers specifically.

Lexers/parsers are as complicated as the grammars they parse. A lexer
for a simple structured text file can be pretty easy to implement; for
instance, JSON is pretty straight-forward, with only a handful of
cases (insignificant whitespace, three keywords, two recursive
structures that start with specific characters ('{' and '['), strings
(which start with '"'), and numbers (which start with a digit or a
hyphen)), so a parser need only look for those few possibilities and
it knows exactly what else to fetch up. I could probably write a JSON
parser in a fairly short space of time, and wouldn't be scared of
digging into the internals of someone else's. It's when the grammar
adds complexities to deal with the real-world issues of full size
programming languages that it becomes hairier. The CPython grammar is
only ~150 lines of fairly readable directives, but the parser that
implements it is ~3500 lines of C code. Pike merges the two into a
YACC file of nearly 5000 lines of highly optimized code (it has
different grammar paths for things a human would consider the same, in
order to produce distinct code). That's where I'm ubercautious.

> For arbitrary code in general, the problem that it may be arbitrarily and 
> unboundedly
> complex/complicated is the oldest problem in computer science: the halting 
> problem.
>
> IOW anyone who thinks that *arbitrary* complexity can *always* be tamed either
> has a visa to utopia or needs to re-evaluate (or get) a CS degree

Exactly.

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

[issue26179] Python C-API "unused-parameter" warnings

[STINNER Victor]

STINNER Victor added the comment:

> Is there an underlying issue in the API?

You can use self if your code. If you don't need it, you can use Py_UNUSED() 
macro available since Python 3.4.

--
nosy: +haypo

___
Python tracker 

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

[issue26179] Python C-API "unused-parameter" warnings

[STINNER Victor]

STINNER Victor added the comment:

Please don't open bug reports to ask questions on your own code. The bug 
tracker is not forum.

--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue26058] PEP 509: Add ma_version to PyDictObject

[Yury Selivanov]

Yury Selivanov added the comment:

> Patch version 5: a global counter is now used to set ma_version field of 
> dictionaries. The global counter is incremented each time that a dictionary 
> is created and each time that a dictionary is modified.

This is great, thank you, Victor.

--

___
Python tracker 

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

[issue21949] Document the Py_SIZE() macro.

[Berker Peksag]

Berker Peksag added the comment:

Thanks for triaging! The relevant commit is 760c5cfacbaa.

--
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> 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

[issue26058] PEP 509: Add ma_version to PyDictObject

[STINNER Victor]

STINNER Victor added the comment:

> This is great, thank you, Victor.

I will update the PEP 509 later for the global counter.

--

___
Python tracker 

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

[issue25907] Documentation i18n: Added trans tags in sphinx templates

[Julien]

Julien added the comment:

And tags for the layout template.

--
Added file: http://bugs.python.org/file41694/i18n-tags-in-layout.patch

___
Python tracker 

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

[issue25907] Documentation i18n: Added trans tags in sphinx templates

[Julien]

Julien added the comment:

And here are the i18n tags for the sidebar, thanks @haypo it was a good idea to 
translate them too ^-^

--
Added file: http://bugs.python.org/file41693/i18n-tags-in-sidebar.patch

___
Python tracker 

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

[issue26145] PEP 511: Add sys.set_code_transformers()

[STINNER Victor]

STINNER Victor added the comment:

Patch version 4: Fix sys_set_code_transformers(), initialize seq to NULL to fix 
a crash on error handling.

--
Added file: http://bugs.python.org/file41695/transformers-4.patch

___
Python tracker 

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

Re: Deprecation warnings for the future async and await keywords

[Marco Buttu]

On 22/01/2016 16:59, Ian Kelly wrote:


On Fri, Jan 22, 2016 at 4:12 AM, Marco Buttu  wrote:



>I enabled the deprecation warnings in Python 3.5.1 and Python 3.6 dev, and I
>noticed that assigning to async or await does not issue any deprecation
>warning:
>
>$ python -Wd -c "import sys; print(sys.version); async = 33"
>3.5.1 (default, Jan 21 2016, 19:59:28)
>[GCC 4.8.4]



They're not reserved words, see
https://www.python.org/dev/peps/pep-0492/#transition-plan


Of course not, in fact I wrote "future keywords" in the subject, because 
they will be keywords in Python 3.7:


https://www.python.org/dev/peps/pep-0492/#deprecation-plans
--
Marco Buttu
--
https://mail.python.org/mailman/listinfo/python-list

one more question on regex

[mg]

python 3.4.3 

import re
re.search('(ab){2}','abzzabab')
<_sre.SRE_Match object; span=(4, 8), match='abab'>

>>> re.findall('(ab){2}','abzzabab')
['ab']

Why for search() the match is 'abab' and for findall the match is 'ab'? 
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue25843] code_richcompare() don't use constant type when comparing code constants

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8e0a736b82ff by Victor Stinner in branch '3.5':
code_richcompare() now uses the constants types
https://hg.python.org/cpython/rev/8e0a736b82ff

--

___
Python tracker 

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

Re: one more question on regex

[Peter Otten]

mg wrote:

> python 3.4.3
> 
> import re
> re.search('(ab){2}','abzzabab')
> <_sre.SRE_Match object; span=(4, 8), match='abab'>
> 
 re.findall('(ab){2}','abzzabab')
> ['ab']
> 
> Why for search() the match is 'abab' and for findall the match is 'ab'?

I suppose someone thought it was convenient for findall to return the 
explicit groups if there are any. If you want the whole match aka group(0) 
you can get that with

>>> re.findall('(?:ab){2}','abzzabab')
['abab']


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

[issue25843] code_richcompare() don't use constant type when comparing code constants

[STINNER Victor]

STINNER Victor added the comment:

Ok, the fix is now pushed to Python 2.7, 3.5 and 3.6.

Thanks Tijs Van Oevelen for your bug report ;-)

A workaround look to define the two lambda functions on two different lines. Or 
maybe cast explicitly to float? I don't think that it's a common bug so you 
should be able to survive with it until the next bugfix version is released :-)

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

[issue21949] Document the Py_SIZE() macro.

[Gedai Tamás Bence]

Gedai Tamás Bence added the comment:

Py_SIZE: https://docs.python.org/3.5/c-api/structures.html#c.Py_SIZE
PyList_New: https://docs.python.org/3.5/c-api/list.html#c.PyList_New

I think they're documented now, so I guess the issue can be closed.

--
nosy: +beng94

___
Python tracker 

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

[issue26181] argparse can't handle positional argument after list (help message is wrong)

[Alex]

New submission from Alex:

This code is meant to take a filename and a list of integers as arguments.  The 
filename is required, the integers are optional:

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('filename')
parser.add_argument('-L', metavar='integer', type=int, nargs='+')
args = parser.parse_args()
print(args)  # see what we got

It produces the following help message:
usage: demo.py [-h] [-L integer [integer ...]] filename

However, the filename argument does not work if it's given in that position 
(after the list of ints).  Instead, it tries to use filename as another list 
element:

$ python demo.py -L 1 2 3 test.txt
usage: demo.py [-h] [-L integer [integer ...]] filename
demo.py: error: argument -L: invalid int value: 'test.txt'

Changing the order of the arguments works as intended:

$ python demo.py test.txt -L 1 2 3 
Namespace(L=[1, 2, 3], filename='test.txt')

Probably the simplest fix would be to amend the help message to show the 
positional argument before the list:

usage: demo.py [-h] filename [-L integer [integer ...]]

--
components: Library (Lib)
messages: 258823
nosy: atpage
priority: normal
severity: normal
status: open
title: argparse can't handle positional argument after list (help message is 
wrong)
type: behavior
versions: Python 2.7, Python 3.4

___
Python tracker 

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

[issue25843] code_richcompare() don't use constant type when comparing code constants

[Roundup Robot]

Roundup Robot added the comment:

New changeset 9e13d97ceca2 by Victor Stinner in branch '2.7':
code_richcompare() now uses the constants types
https://hg.python.org/cpython/rev/9e13d97ceca2

--

___
Python tracker 

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

[issue24520] Stop using deprecated floating-point environment functions on FreeBSD

[STINNER Victor]

STINNER Victor added the comment:

> @koobs: sorry, 3.4 now only accept security fixes :-p

I wrote a table giving the status of each Python branch to know which ones 
still accept bugfixes or not:
https://docs.python.org/devguide/#status-of-python-branches

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

[issue26058] PEP 509: Add ma_version to PyDictObject

[STINNER Victor]

STINNER Victor added the comment:

Patch version 5: a global counter is now used to set ma_version field of 
dictionaries. The global counter is incremented each time that a dictionary is 
created and each time that a dictionary is modified.

A dictionary version is now unique: two dictionaries cannot have the same 
version. So if a guard stores a version, the check on the version will fail if 
a different dictionary is used.

--
Added file: http://bugs.python.org/file41691/dict_version-5.patch

___
Python tracker 

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

[issue26145] PEP 511: Add sys.set_code_transformers()

[STINNER Victor]

STINNER Victor added the comment:

Rebased patch.

--
Added file: http://bugs.python.org/file41692/transformers-3.patch

___
Python tracker 

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