[issue34974] bytes and bytearray constructors replace unexpected exceptions

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 43308dfc3335906cfefe9f14a44e468935f3c321 by Serhiy Storchaka in 
branch '2.7':
[2.7] bpo-34974: Do not replace unexpected errors in bytearray(). (GH-9852) 
(GH-9885)
https://github.com/python/cpython/commit/43308dfc3335906cfefe9f14a44e468935f3c321


--

___
Python tracker 

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

Re: ESR "Waning of Python" post

[dieter]

Marko Rauhamaa  writes:
> dieter :
> ...
>> Definitely. The application concerned was a long running web application;
>> caching was an important feature to speed up its typical use cases.
>
> As an optimization technique, I suggest turning the cache into a "binary
> blob" opaque to GC, or using some external component like SQLite.

This was a Python application and as such, it was primarily working with
Python objects. And it was a complex application heavily depending
on subframeworks, many of them internally using caching to speed
things up, the details hidden from the application.
Redesigning the application to use an alternative caching was
out of question.


> Keeping the number of long-term objects low is key.

Right, if I need near realtime behaviour and must live
with [C]Python's garbage collector.

But, a web application does usually not need near realtime behaviour.
An occasional (maybe once in a few days) garbage collection and
associated reduced response time is acceptable.
A problem only arises if a badly designed component produces
quite frequently hundreds of thousands of temporary objects
likely triggering (frequent) garbage collections.


> Note that Python creates a temporary object every time you invoke a
> method. CPython removes them quickly through reference counting, but
> other Python implementations just let GC deal with them, and that's
> generally ok.

The initial point has been that you must carefully look at the context
for which you design a solution and choose appropriately (among
other the implementation language).
In my case, the web application framework was fixed ("Zope")
and therefore the language ("Python") and its implementation ("CPython").
"Normal" temporary objects did not pose a problem (due to reference
counting); only the mass creation of temporary objects can
be problematic (as GC is triggered before the temporary objects
are released again (due to reference counting).

>
>
> Marko

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

Re: Python indentation (3 spaces)

[Chris Angelico]

On Mon, Oct 15, 2018 at 3:51 PM Marko Rauhamaa  wrote:
> The two-space indentation is the out-of-the-box default for emacs.
> However, the tab collapsing principle is a universal default. If you go
> against it, you will have to educate more tools than your editor. For
> example, try running this Python snippet (in REPL or as a program):
>
> for i in range(32):
> print("x{}\ty".format(" " * i))
>

I don't understand your point here. It prints a letter, then some
spaces, then a tab, then another letter. On my terminal, that displays
the tab by advancing to the next tab position. If I highlight to
select, it's obvious that the spaces have not been collapsed or
converted in any way; it is indeed printing that many spaces, then a
tab. Universal default? Not very.

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +9248

___
Python tracker 

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

[issue34572] C unpickling bypasses import thread safety

[Tim Burgess]

Tim Burgess  added the comment:

Hi!  Just wondering if there is anything I can do to move this along?

--

___
Python tracker 

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

Re: Python indentation (3 spaces)

[Marko Rauhamaa]

Chris Angelico :
> I'm saying I have never seen is this:
>
> On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
>> However, it is trumped by an older
>> convention whereby the indentation levels go as follows:
>>
>>0:
>>1: SPC SPC
>>2: SPC SPC SPC SPC
>>3: SPC SPC SPC SPC SPC SPC
>>4: TAB
>>5: TAB SPC SPC
>>6: TAB SPC SPC SPC SPC
>>7: TAB SPC SPC SPC SPC SPC SPC
>>8: TAB TAB
>
> Specifically that two-space indents and tab-collapsing are a
> *convention*. I have never seen this used anywhere, much less seen it
> commonly enough to call it a convention.

The two-space indentation is the out-of-the-box default for emacs.
However, the tab collapsing principle is a universal default. If you go
against it, you will have to educate more tools than your editor. For
example, try running this Python snippet (in REPL or as a program):

for i in range(32):
print("x{}\ty".format(" " * i))


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

[issue34986] python finds test modules from the wrong directory during PGO build

[Kal Sze]

Kal Sze  added the comment:

Oops, sorry for the noise. This is mostly a duplicate of #34985 because the 
crash log attachment was too big and caused the issue tracker's proxy server to 
return an error code, so I thought the initial bug report creation failed. An 
e-mail confirmation arrived only much later.

--
resolution:  -> duplicate
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: Python indentation (3 spaces)

[Chris Angelico]

On Mon, Oct 15, 2018 at 2:51 PM Alan Bawden  wrote:
>
> Chris Angelico  writes:
> > On Mon, Oct 15, 2018 at 9:56 AM Alan Bawden  wrote:
> > > In my experience this is a very common way to assume that tabs will be
> > > interpreted.  Virtually every source-code file I have encountered since 
> > > the
> > > mid 1970s (for any programming language or operating system) has assumed
> > > either this convention or, slightly less often, its 4-column variant.
> > >
> > > It's surprising that you've never encountered it.
> >
> > I've seen the four-column variant, but never the two. Maybe I just
> > move in different circles. In any case, I wouldn't say that "two space
> > indents, collapsed to a tab after eight" is somehow a universal
> > convention any more than four-space with or without collapsing.
>
> I think we're talking past each other somehow here.  I described the common
> 8-column interpretation, and the less common 4-column interpretation.  I
> did not mention, nor do I ever remember encountering in the wild, the
> 2-column variation.  (I _have_ seen the 10-column variation used -- it was
> the standard on Multics.)
> [chomp details]

I believe we are in agreement here - that it is common for a tab to be
interpreted as equivalent to eight spaces, but also that this is
definitely not the definition of the character. The convention that
I'm saying I have never seen is this:

On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
> However, it is trumped by an older
> convention whereby the indentation levels go as follows:
>
>0:
>1: SPC SPC
>2: SPC SPC SPC SPC
>3: SPC SPC SPC SPC SPC SPC
>4: TAB
>5: TAB SPC SPC
>6: TAB SPC SPC SPC SPC
>7: TAB SPC SPC SPC SPC SPC SPC
>8: TAB TAB

Specifically that two-space indents and tab-collapsing are a
*convention*. I have never seen this used anywhere, much less seen it
commonly enough to call it a convention.

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

Re: Python indentation (3 spaces)

[Alan Bawden]

Chris Angelico  writes:
> On Mon, Oct 15, 2018 at 9:56 AM Alan Bawden  wrote:
> > In my experience this is a very common way to assume that tabs will be
> > interpreted.  Virtually every source-code file I have encountered since the
> > mid 1970s (for any programming language or operating system) has assumed
> > either this convention or, slightly less often, its 4-column variant.
> >
> > It's surprising that you've never encountered it.
> 
> I've seen the four-column variant, but never the two. Maybe I just
> move in different circles. In any case, I wouldn't say that "two space
> indents, collapsed to a tab after eight" is somehow a universal
> convention any more than four-space with or without collapsing.

I think we're talking past each other somehow here.  I described the common
8-column interpretation, and the less common 4-column interpretation.  I
did not mention, nor do I ever remember encountering in the wild, the
2-column variation.  (I _have_ seen the 10-column variation used -- it was
the standard on Multics.)

The ANSI standard for ASCII only describes the tab character as follows:

   7.21 HT (HORIZONTAL TABULATION). A format effector that causes the
   active position to advance to the next predetermined character position.

This says nothing about where those "predetermined character positions"
happen to be.  They could be set at columns 5, 17, 23, 99 and 100, or they
could be set every N columns for some N, or wherever you want, it's up to
you.  (Note that this is exactly the way mechanical typewriters used to
work: "tab stops" were originally physical sliders that you would position
manually, and then when you pressed the "tab" key, a spring would pull the
carriage holding the paper to the left until it would be physically
_stopped_ by the tab stop.)

Given that the ANSI standard is silent on where the tab stops should be set
for the HT character, we can only ask where they are set _in practice_,
based on looking at he contents of files and the behavior of various pieces
of software.  For example, in the Linux termios(3) manual page describes
one of the options you can set to control output to a terminal:

   TABDLY Horizontal tab delay mask.  Values are TAB0, TAB1, TAB2, TAB3 (or
  XTABS).  A value of TAB3, that is, XTABS, expands tabs to spaces
  (with tab stops every eight columns).

So if tabs are going to be converted to spaces on output, your only choice
is the every-8-columns interpretation.  (Interestingly, setting TABDLY to
TAB3 to convert tabs to spaces is part of POSIX, but the POSIX standard
does _not_ appear to specify the positions of the tab stops!)

The 8-column interpretation is also the default behavior in every text
editor I have ever used (except, as I noted above, on Multics!).

The 8-column interpretation also seems most common in source code files,
although 4-column files do show up occasionally.

So when you say:

   I've literally NEVER come across this as a convention.  Not a single
   file that I have ever worked with has used it.  Where is this convention
   from?

I feel that there _must_ be some misunderstanding here.  Maybe you
misinterpreted Marko's description of how 8-column tabs are used to achieve
2-columns-per-level indentation.  Or maybe I'm misunderstanding what you
mean by "convention".  Or maybe one of us just beamed in from parallel
universe...

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

[issue34986] python finds test modules from the wrong directory during PGO build

[Kal Sze]

New submission from Kal Sze :

OS: Ubuntu Desktop 18.04.1 x86-64
Python 3.7.0

When trying to build Python 3.7 from source, with the `--enable-shared 
--enable-optimizations --with-lto` configure options, python needs to run the 
test suite in order to generate PGO data. However, it turns out that it would 
find test modules from the wrong directory, if there is already another version 
of Python 3 installed system-wide (Ubuntu 18.04 comes with Python 3.6 
pre-installed).

I found out because Ubuntu's automatic crash reporter caught a core dump during 
`python -m tests.regrtest` and I could see that python found the tests.regrtest 
module at `/usr/lib/python3.6/test/regrtest.py`.

In the end, the build is reported as "successful", I guess it's because the 
Makefile expects it the crash anyway. In any case, it still seems wrong because 
it means the wrong test suite is run.

Ubuntu's crash report in raw format is attached, for anybody who knows how to 
read it (it's in plain text anyway)

--
components: Build
files: _usr_lib_python3.6_test_regrtest.py.1000.crash
messages: 327726
nosy: Kal Sze2
priority: normal
severity: normal
status: open
title: python finds test modules from the wrong directory during PGO build
type: behavior
versions: Python 3.7
Added file: 
https://bugs.python.org/file47868/_usr_lib_python3.6_test_regrtest.py.1000.crash

___
Python tracker 

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

[issue34985] python finds test modules from the wrong directory during PGO build

[Kal Sze]

New submission from Kal Sze :

OS: Ubuntu Desktop 18.04.1 x86-64
Python 3.7.0

When trying to build Python 3.7 from source, with the `--enable-shared 
--enable-optimizations --with-lto` configure options, python needs to run the 
test suite in order to generate PGO data. However, it turns out that it would 
find test modules from the wrong directory, if there is already another version 
of Python 3 installed system-wide (Ubuntu 18.04 comes with Python 3.6 
pre-installed).

I found out because Ubuntu's automatic crash reporter caught a core dump during 
`python -m tests.regrtest` and I could see that python found the tests.regrtest 
module at `/usr/lib/python3.6/test/regrtest.py`.

In the end, the build is reported as "successful", I guess it's because the 
Makefile expects it the crash anyway. In any case, it still seems wrong because 
it means the wrong test suite is run.

I have uploaded Ubuntu's crash report in raw format here, for anybody who knows 
how to read it (it's in plain text anyway): 
https://www.dropbox.com/s/6ihxoouoqe1k98f/_usr_lib_python3.6_test_regrtest.py.1000.crash?dl=0

--
components: Build
messages: 327725
nosy: Kal Sze2
priority: normal
severity: normal
status: open
title: python finds test modules from the wrong directory during PGO build
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue33450] unexpected EPROTOTYPE returned by sendto on MAC OSX

[Eamonn Nugent]

Eamonn Nugent  added the comment:

Fwiw, this also happens in asyncio. Theoretically, I *think* you could wrap a 
try-except as a monkey patch.

My stack trace is:

Fatal write error on socket transport
protocol: 
transport: <_SelectorSocketTransport fd=163 read=polling write=>
Traceback (most recent call last):
  File 
"/usr/local/Cellar/python/3.6.5_1/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/selector_events.py",
 line 761, in write
n = self._sock.send(data)
OSError: [Errno 41] Protocol wrong type for socket

I can try to PR the fix mentioned by @ronaldoussoren, though it might take me a 
bit. I'm happy to do whatever to get this fixed, though, since it's flooding my 
terminal with several hundred errors every time it happens...

--
nosy: +Eamonn Nugent

___
Python tracker 

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

[issue32321] functools.reduce has a redundant guard or needs a pure Python fallback

[Braden Groom]

Change by Braden Groom :


--
pull_requests: +9246

___
Python tracker 

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

Re: Python indentation (3 spaces)

[Chris Angelico]

On Mon, Oct 15, 2018 at 9:56 AM Alan Bawden  wrote:
> In my experience this is a very common way to assume that tabs will be
> interpreted.  Virtually every source-code file I have encountered since the
> mid 1970s (for any programming language or operating system) has assumed
> either this convention or, slightly less often, its 4-column variant.
>
> It's surprising that you've never encountered it.

I've seen the four-column variant, but never the two. Maybe I just
move in different circles. In any case, I wouldn't say that "two space
indents, collapsed to a tab after eight" is somehow a universal
convention any more than four-space with or without collapsing.

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

Re: Fwd: socket: Too many open files

[Cameron Simpson]

On 14Oct2018 20:24, Shakti Kumar  wrote:

On 13Oct2018 14:10, Shakti Kumar  wrote:

I’m running a script which basically does a traceroute to the list of
hosts
provided, and then pulls up some info by logging in to gateways in the

path.

I am running this script for a list of almost 40k hosts in our data

centers.

Also, I am using commands module to get the traceroute output.

out = commands.getstatusoutput('traceroute ' + ip)

However I observe that this particular line is failing with socket error
after I reach some 5k to 6k hosts.

[...]

In fact, given that it is file descriptors, maybe sockets are not what
is leaking?



From another terminal, see what your Python programme has open when this
happens with "lsof -n -p pid-of-python-programme". Maybe the leaks are
pipes, or connections from your "logging in to gateways in the path"
code. It may be as simple as you not closing files or connections.


Thanks Cameron, I still cant get over the fact that you were able to pin
point the issue even without looking at my code XD


Well it seemed likely that traceroute itself was not the cause because 
as you expected, when the command terminates its resources should clear 
up. That is one of the nice things about external executables - the OS 
tidies up their leaks, if any. (TCP sockets tend to hand around for a 
while to catch stray resent packets, but traceroute doesn't use TCP.)



Indeed when I started looking for sockets, I realised I was not closing
connections to ACI hosts in our datacentres, and the error was starting to
pop up at around 2900 to 3k TCP connections open to the hosts. XD


I think the takea away from my post, if any, is the usefulness of some 
external commands for inspecting behaviour if a problem seems 
intractable by inspection (eg "in Python" debugging, including prints 
etc).


Tools like strace, netstat and lsof are really good for seeing what the 
program is doing/leaking/misusing at an OS level. Even for opaque things 
like third party Java programmes, etc.


In your particular case, you're out of sockets (or possibly file 
desciptors). So use netstat to inspect the open sockets (and on Linux, 
"the open sockets for a particular PID" is an answerable question).  
Also, lsof will show your programme's open files, including the sockets.


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

Re: Python indentation (3 spaces)

[Alan Bawden]

Chris Angelico  writes:
> On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
> > Chris Angelico :
...
> > That *could* be the situation. However, it is trumped by an older
> > convention whereby the indentation levels go as follows:
> >
> >0:
> >1: SPC SPC
> >2: SPC SPC SPC SPC
> >3: SPC SPC SPC SPC SPC SPC
> >4: TAB
> >5: TAB SPC SPC
> >6: TAB SPC SPC SPC SPC
> >7: TAB SPC SPC SPC SPC SPC SPC
> >8: TAB TAB
> 
> I've literally NEVER come across this as a convention. Not a single
> file that I have ever worked with has used it. Where is this
> convention from?

I just picked a C source code file AT RANDOM from the FreeBSD source tree
on the machine I'm using to compose this message
(/usr/src/gnu/usr.bin/man/man/glob.c), and I find that, as I expected, it
uses exactly that convention.  And in that file, the comments don't line up
as the author clearly intended unless the tab stops are set every 8
columns.

In my experience this is a very common way to assume that tabs will be
interpreted.  Virtually every source-code file I have encountered since the
mid 1970s (for any programming language or operating system) has assumed
either this convention or, slightly less often, its 4-column variant.

It's surprising that you've never encountered it.

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

Re: Python indentation (3 spaces)

[Cameron Simpson]

On 15Oct2018 00:33, Peter J. Holzer  wrote:

On 2018-10-15 09:06:11 +1100, Chris Angelico wrote:

On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
> Chris Angelico :
> > Tabs for indentation have semantic meaning. Top-level has zero tabs.
> > One indentation level is represented by one tab. Two indentation
> > levels? Two tabs. It's about as perfect a representation as you could
> > hope for.
>
> That *could* be the situation. However, it is trumped by an older
> convention whereby the indentation levels go as follows:
>
>0:
>1: SPC SPC
>2: SPC SPC SPC SPC
>3: SPC SPC SPC SPC SPC SPC
>4: TAB
>5: TAB SPC SPC
>6: TAB SPC SPC SPC SPC
>7: TAB SPC SPC SPC SPC SPC SPC
>8: TAB TAB


That's not using tabs for indentation, that's using tabs for compressing
spaces (somebody already mentioned that in this thread).



I've literally NEVER come across this as a convention. Not a single
file that I have ever worked with has used it. Where is this
convention from?


It's something vi does by default, and apparently emacs as well.
In the 1970's saving space by replacing sequences of 8 spaces
with tabs seemed lika a good idea.

There are workarounds in vi(m), but I'm not sure if you can get rid of
that behaviour completely. I'm sure it is possible in emacs.


I'm a "just use spaces" guy. I use the tab _key_ as a shortcut to do a 
bunch of spaces.


My vim setup has this:

 set expandtab

which turns them into spaces.

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

Re: Python indentation (3 spaces)

[Peter J. Holzer]

On 2018-10-15 09:06:11 +1100, Chris Angelico wrote:
> On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
> > Chris Angelico :
> > > Tabs for indentation have semantic meaning. Top-level has zero tabs.
> > > One indentation level is represented by one tab. Two indentation
> > > levels? Two tabs. It's about as perfect a representation as you could
> > > hope for.
> >
> > That *could* be the situation. However, it is trumped by an older
> > convention whereby the indentation levels go as follows:
> >
> >0:
> >1: SPC SPC
> >2: SPC SPC SPC SPC
> >3: SPC SPC SPC SPC SPC SPC
> >4: TAB
> >5: TAB SPC SPC
> >6: TAB SPC SPC SPC SPC
> >7: TAB SPC SPC SPC SPC SPC SPC
> >8: TAB TAB

That's not using tabs for indentation, that's using tabs for compressing
spaces (somebody already mentioned that in this thread).


> I've literally NEVER come across this as a convention. Not a single
> file that I have ever worked with has used it. Where is this
> convention from?

It's something vi does by default, and apparently emacs as well.
In the 1970's saving space by replacing sequences of 8 spaces
with tabs seemed lika a good idea.

There are workarounds in vi(m), but I'm not sure if you can get rid of
that behaviour completely. I'm sure it is possible in emacs.

> > Your scheme also is ad hoc in that it doesn't follow its logic to other
> > ASCII control characters. Why not use VT to separate methods? Why not
> > use US to separate operators from operands? Why not use RS to separate
> > the operands of optional arguments? Why not use GS to separate logical
> > blocks of code? After all, those schemes would allow people to
> > personalize the visual representation of more aspects of the source
> > code.
> 
> You're most welcome to use VT between methods.

I sometimes use FF so separate sections of code in longer files. Had to
stop that in Django projects because it messes up the stack traces.

> Not sure what you mean by US, RS, and GS,

Unit separator, record separator, group separator (and FS is file
separator). I think they were intended for a CSV-like file format, but I
have never seen them in use (outside of my own projects).

hp

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


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

[issue24653] Mock.assert_has_calls([]) is surprising for users

[Srinivas Reddy T]

Change by Srinivas  Reddy T :


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

___
Python tracker 

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

Re: Python indentation (3 spaces)

[Chris Angelico]

On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
>
> Chris Angelico :
>
> > Tabs for indentation have semantic meaning. Top-level has zero tabs.
> > One indentation level is represented by one tab. Two indentation
> > levels? Two tabs. It's about as perfect a representation as you could
> > hope for. If you like your indentation levels to be as wide as four
> > spaces, you can have that. I could have them at eight, and it wouldn't
> > make a difference. And if someone messes up their code by using tabs
> > to align all their comments, reject that code at code review time.
> > This ain't rocket science.
>
> That *could* be the situation. However, it is trumped by an older
> convention whereby the indentation levels go as follows:
>
>0:
>1: SPC SPC
>2: SPC SPC SPC SPC
>3: SPC SPC SPC SPC SPC SPC
>4: TAB
>5: TAB SPC SPC
>6: TAB SPC SPC SPC SPC
>7: TAB SPC SPC SPC SPC SPC SPC
>8: TAB TAB

I've literally NEVER come across this as a convention. Not a single
file that I have ever worked with has used it. Where is this
convention from?

> Your scheme also is ad hoc in that it doesn't follow its logic to other
> ASCII control characters. Why not use VT to separate methods? Why not
> use US to separate operators from operands? Why not use RS to separate
> the operands of optional arguments? Why not use GS to separate logical
> blocks of code? After all, those schemes would allow people to
> personalize the visual representation of more aspects of the source
> code.

You're most welcome to use VT between methods. Not sure what you mean
by US, RS, and GS, but if they count as whitespace, you are absolutely
welcome to use them. I don't see why you have to use ALL of them if
you use any, but hey, if you want to, nobody's stopping you. What's
the issue here?

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

Re: Python indentation (3 spaces)

[Marko Rauhamaa]

Chris Angelico :

> Tabs for indentation have semantic meaning. Top-level has zero tabs.
> One indentation level is represented by one tab. Two indentation
> levels? Two tabs. It's about as perfect a representation as you could
> hope for. If you like your indentation levels to be as wide as four
> spaces, you can have that. I could have them at eight, and it wouldn't
> make a difference. And if someone messes up their code by using tabs
> to align all their comments, reject that code at code review time.
> This ain't rocket science.

That *could* be the situation. However, it is trumped by an older
convention whereby the indentation levels go as follows:

   0:
   1: SPC SPC
   2: SPC SPC SPC SPC
   3: SPC SPC SPC SPC SPC SPC
   4: TAB
   5: TAB SPC SPC
   6: TAB SPC SPC SPC SPC
   7: TAB SPC SPC SPC SPC SPC SPC
   8: TAB TAB

That's how emacs indents source code files out of the box, BTW.

Moreover:

   SPC TAB = TAB
   SPC SPC SPC SPC SPC SPC SPC SPC = TAB

etc.

This older convention is honored by Python2 as well.

This older convention has been honored by many operating systems (at
least UNIX, CP/M and MS-DOS).

If I had to choose between your scheme and the older scheme, I'd choose
the older one.

Instead, I have chosen to banish HT as an unnecessary distraction.

Your scheme also is ad hoc in that it doesn't follow its logic to other
ASCII control characters. Why not use VT to separate methods? Why not
use US to separate operators from operands? Why not use RS to separate
the operands of optional arguments? Why not use GS to separate logical
blocks of code? After all, those schemes would allow people to
personalize the visual representation of more aspects of the source
code.


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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[miss-islington]

miss-islington  added the comment:


New changeset 08ba7eb89d5353af31ef9e66a5337abea1b676ef by Miss Islington (bot) 
in branch '3.6':
bpo-34974: Do not replace unexpected errors in bytes() and bytearray(). 
(GH-9852)
https://github.com/python/cpython/commit/08ba7eb89d5353af31ef9e66a5337abea1b676ef


--

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[miss-islington]

miss-islington  added the comment:


New changeset 1370832af24cc6f0f464354b9ec3ecdb343d35ce by Miss Islington (bot) 
in branch '3.7':
bpo-34974: Do not replace unexpected errors in bytes() and bytearray(). 
(GH-9852)
https://github.com/python/cpython/commit/1370832af24cc6f0f464354b9ec3ecdb343d35ce


--
nosy: +miss-islington

___
Python tracker 

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

[issue34848] range.index only takes one argument when it's documented as taking the usual 3

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +9244

___
Python tracker 

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

[issue34848] range.index only takes one argument when it's documented as taking the usual 3

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +9243

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset e890421e334ccf0c000c6b29c4a521d86cd12f47 by Serhiy Storchaka in 
branch 'master':
bpo-34974: Do not replace unexpected errors in bytes() and bytearray(). 
(GH-9852)
https://github.com/python/cpython/commit/e890421e334ccf0c000c6b29c4a521d86cd12f47


--

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[miss-islington]

Change by miss-islington :


--
pull_requests: +9241

___
Python tracker 

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

[issue34974] bytes and bytearray constructors replace unexpected exceptions

[miss-islington]

Change by miss-islington :


--
pull_requests: +9242

___
Python tracker 

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

[issue9453] pulldom.SAX2DOM Doesn't support processing instructions before the root element

[Tal Einat]

Tal Einat  added the comment:

Proposing removal of SAX2DOM doesn't seem unreasonable to me. However, 
considering it hasn't been removed so far, we'll need good reason to do so 
since that would break backwards compatibility.

Jonathan, if the solution to this is simple, I say go for it and make a PR.

--

___
Python tracker 

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

[issue34848] range.index only takes one argument when it's documented as taking the usual 3

[Srinivas Reddy T]

Change by Srinivas  Reddy T :


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

___
Python tracker 

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

[issue17561] Add socket.create_server_sock() convenience function

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Since Tulip/asyncio has gone through a lot of development since this issue was 
added, I wasn't sure if this has been included already or if there was still 
interest in it.  In either case, I think it might be able to be closed, but I 
wanted to make sure first.  Thanks!

--
nosy: +asvetlov, cheryl.sabella

___
Python tracker 

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

[issue34976] IDLE: Replace the search dialog with a search bar

[Cheryl Sabella]

Cheryl Sabella  added the comment:

+1 on adding this to IDLE

I haven't looked at the code or all the details yet, but just downloading the 
patch and running code in IDLE, this is a nice change.

--

___
Python tracker 

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

Re: Python indentation (3 spaces)

[Chris Angelico]

On Mon, Oct 15, 2018 at 1:35 AM Grant Edwards  wrote:
>
> On 2018-10-14, Christian Gollwitzer  wrote:
> > Am 14.10.18 um 02:45 schrieb Grant Edwards:
> >> On 2018-10-13, Peter J. Holzer  wrote:
> >>>
>  For "just use tabs" to work, all of those tools would have to
>  magically recognize that they're looking at Python source and adjust
>  the tab size accordingly.  That isn't going to happen.
> >>>
> >>> Well, no. The idea of "just use tabs" isn't have a different tab width
> >>> per language, but a different tab width per user.
> >>
> >> You work in a different environment than I do.  for me, tab width
> >> varies from one project to another (sometimes even in the same
> >> language).  I don't get to pick just one tab width.
> >
> > But if you use only tabs for indentation, the tab width setting simply
> > does not matter.
>
> > There is a disadvantage only if you try to align something which is NOT
> > an indentation level, e.g. when there are big string constants or list
> > constants etc.
>
> Exactly.  In my experience, people who use tabs for indentation always
> end up using them for other things as well: aligning comments or columns
> in data tables, etc.
>

Well, I don't, and I DO use tabs for indentation. So how about we
restrict this discussion to indentation, and not worry about other
things people might also use tabs for?

Tabs for indentation have semantic meaning. Top-level has zero tabs.
One indentation level is represented by one tab. Two indentation
levels? Two tabs. It's about as perfect a representation as you could
hope for. If you like your indentation levels to be as wide as four
spaces, you can have that. I could have them at eight, and it wouldn't
make a difference. And if someone messes up their code by using tabs
to align all their comments, reject that code at code review time.
This ain't rocket science.

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

[issue34939] Possibly spurious SyntaxError: annotated name can't be global

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

[issue9453] pulldom.SAX2DOM Doesn't support processing instructions before the root element

[Jonathan Gossage]

Jonathan Gossage  added the comment:

This test case demonstrates that the issue still exists in 3.8. The fix is 
relatively simple but I am unsure whether it is worthwhile as the original 
comments on the quality and usability of SAX2DOM are spot on. My recommendation 
would be to mark it as pending and close it at the end of a month if no-one 
submits a fix.

--
nosy: +Jonathan.Gossage, taleinat
Added file: https://bugs.python.org/file47867/issue9453.py

___
Python tracker 

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

[issue34939] Possibly spurious SyntaxError: annotated name can't be global

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset de2aea0ff02fa9486365ce9d215bef150fae3a0b by Pablo Galindo in 
branch 'master':
bpo-34939: Allow annotated global names in module namespace (GH-9844)
https://github.com/python/cpython/commit/de2aea0ff02fa9486365ce9d215bef150fae3a0b


--
nosy: +pablogsal

___
Python tracker 

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

[issue29159] Regression in bytes constructor

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests:  -1003

___
Python tracker 

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

[issue34984] Improve error messages in bytes and bytearray constructors

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue34984] Improve error messages in bytes and bytearray constructors

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

The proposed PR improves error messages in bytes and bytearray constructors.

1. When pass only encoding or errors to the bytes or bytearray constructor, it 
raises a TypeError with the message "encoding or errors without sequence 
argument". But the required argument is not a sequence, it is a string. 
"sequence argument" will be replaced with "a string argument".

2. Also "encoding or errors" will be replaced with just "encoding" or "errors", 
as in bytes(0, 'utf-8') and bytes(0, errors='utf-8').

3. When pass an unsupported type to the bytearray constructor, it raises  a 
TypeError with the message like "'float' object is not iterable". It will be 
replaced with "cannot convert 'float' object to bytearray" (similar to the 
message raised in the bytes constructor).

4. When pass an unsupported type to the bytearray's extend() method, it raises  
a TypeError with the message like "'float' object is not iterable". It will be 
replaced with "can't extend bytearray with float".

--
assignee: serhiy.storchaka
components: Interpreter Core
messages: 327715
nosy: r.david.murray, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve error messages in bytes and bytearray constructors
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue34521] Multiple tests (test_socket, test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer lengths, causing failures on FreeBSD CURRENT

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset bd036d3d15fc1310ccc32a43a3296b8c157ac221 by Pablo Galindo in 
branch 'master':
bpo-34521: Add NEWS entry for changes in GH-9613 (GH-9850)
https://github.com/python/cpython/commit/bd036d3d15fc1310ccc32a43a3296b8c157ac221


--

___
Python tracker 

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

[issue20216] Misleading docs for sha1, sha256, sha512, md5 modules

[Srinivas Reddy T]

Change by Srinivas  Reddy T :


--
pull_requests: +9238
stage: needs patch -> patch review

___
Python tracker 

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

[issue34983] expose symtable.Symbol.is_nonlocal()

[Pablo Galindo Salgado]

New submission from Pablo Galindo Salgado :

The symtable has information about if a particular symbol is nonlocal though 
the DEF_LOCAL flag but this information is not exposed in symtable.py, making 
impossible to ask if a symbol is declared as nonlocal using the python symtable 
module.

--
components: Interpreter Core
messages: 327713
nosy: pablogsal
priority: normal
severity: normal
status: open
title: expose symtable.Symbol.is_nonlocal()
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue34983] expose symtable.Symbol.is_nonlocal()

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

Fwd: socket: Too many open files

[Shakti Kumar]

>On 13Oct2018 14:10, Shakti Kumar  wrote:
>>I’m running a script which basically does a traceroute to the list of
>>hosts
>>provided, and then pulls up some info by logging in to gateways in the
path.
>>I am running this script for a list of almost 40k hosts in our data
centers.
>>Also, I am using commands module to get the traceroute output.
>>
>>out = commands.getstatusoutput('traceroute ' + ip)
>>
>>However I observe that this particular line is failing with socket error
>>after I reach some 5k to 6k hosts.
>>I know commands module is using pipes to execute the given command and
this
>>is one reason for exhaustion of file descriptors.
>>Any suggestions for improving this and getting a workaround?

>I'd figure out where your file descriptors are going.

>Is traceroute leaving sockets littering your system? If you're on Linux
>this command:

>  netstat -anp

>will show you all the sockets, their state, and the pids of the
>processes which own them. Does your script cause sockets to accrue after
>the traceroutes?

>If you write a trivial shell script to do the traceroutes:

>while read ip
>do
>traceroute $ip
>  done does it also exhibit the problem?

>The if doesn't, then traceroute may not be the problem and something
>else is leaking file descriptors.

>In fact, given that it is file descriptors, maybe sockets are not what
>is leaking?

>From another terminal, see what your Python programme has open when this
>happens with "lsof -n -p pid-of-python-programme". Maybe the leaks are
>pipes, or connections from your "logging in to gateways in the path"
>code. It may be as simple as you not closing files or connections.

>Cheers,
>Cameron Simpson 

Thanks Cameron, I still cant get over the fact that you were able to pin
point the issue even without looking at my code XD
Indeed when I started looking for sockets, I realised I was not closing
connections to ACI hosts in our datacentres, and the error was starting to
pop up at around 2900 to 3k TCP connections open to the hosts. XD

Thanks Jonathan for pointing me to more apt functions. It helped a lot :)

Regards,
Shakti.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

[Grant Edwards]

On 2018-10-14, Christian Gollwitzer  wrote:
> Am 14.10.18 um 02:45 schrieb Grant Edwards:
>> On 2018-10-13, Peter J. Holzer  wrote:
>>>
 For "just use tabs" to work, all of those tools would have to
 magically recognize that they're looking at Python source and adjust
 the tab size accordingly.  That isn't going to happen.
>>>
>>> Well, no. The idea of "just use tabs" isn't have a different tab width
>>> per language, but a different tab width per user.
>> 
>> You work in a different environment than I do.  for me, tab width
>> varies from one project to another (sometimes even in the same
>> language).  I don't get to pick just one tab width.
>
> But if you use only tabs for indentation, the tab width setting simply 
> does not matter.

> There is a disadvantage only if you try to align something which is NOT 
> an indentation level, e.g. when there are big string constants or list 
> constants etc.

Exactly.  In my experience, people who use tabs for indentation always
end up using them for other things as well: aligning comments or columns
in data tables, etc.

-- 
Grant

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

[issue34982] re.sub() different behavior in 3.7

[purificant]

purificant  added the comment:

Great, thank you for explaining. My specific use case can be fixed by replacing 
* with + as per your suggestion.

--

___
Python tracker 

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

[issue34982] re.sub() different behavior in 3.7

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Yes, this is an intended change. Your pattern matches an empty string at the 
end of the input string. It was a bug in earlier Python versions that re.sub() 
didn't replace empty matches adjacent to a previous non-empty match.

It is not clear what is the purpose of your code, but adding anchors or 
replacing * with + usually helps.

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

Re: [Python-Dev] [RELEASE] Python 3.7.1rc2 and 3.6.7rc2 now available for testing

[Ray Donnelly]

Hi Ned,

I tried to report this on bpo, but it's not letting me log in for some reason.

I ran into a problem trying to build 3.7.1-rc2 on macOS for Anaconda
Distribution. I debugged it a little so hopefully this is useful?

The error is:

checking whether float word ordering is bigendian... unknown

This happens because by default, clang on macOS still generates 'fat'
binaries so the greps introduced in
https://github.com/python/cpython/commit/2a9c3805ddedf282881ef7811a561c70b74f80b1
find both noonsees and seesnoon.

If we add `-arch x86_64` to our `CFLAGS` then we get a successful
build, so perhaps this should be added in the configure stuff when we
detect macOS?

Best regards,

Ray Donnelly,
Anaconda Inc,
On Sat, Oct 13, 2018 at 10:51 PM Ned Deily  wrote:
>
> Python 3.7.1rc2 and 3.6.7rc2 are now available. 3.7.1rc2 is a release
> preview of the first maintenance release of Python 3.7, the latest
> feature release of Python. 3.6.7rc2 is a release preview of the next
> maintenance release of Python 3.6, the previous feature release of
> Python. Assuming no further critical problems are found prior to
> 2018-10-20, no code changes are planned between these release
> candidates and the final releases. These release candidates are
> intended to give you the opportunity to test the new security and bug
> fixes in 3.7.1 and 3.6.7. We strongly encourage you to test your
> projects and report issues found to bugs.python.org as soon as
> possible. Please keep in mind that these are preview releases and,
> thus, their use is not recommended for production environments.
>
> You can find these releases and more information here:
> https://www.python.org/downloads/release/python-371rc2/
> https://www.python.org/downloads/release/python-367rc2/
>
> --
>   Ned Deily
>   n...@python.org -- []
>
> ___
> Python-Dev mailing list
> python-...@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/mingw.android%40gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34982] re.sub() different behavior in 3.7

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue34982] re.sub() different behavior in 3.7

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks for the report. git bisect tells me this change was introduced with 
fbb490fd2f38bd817d99c20c05121ad0168a38ee (issue32308)

# ../backups/bpo34982.py
import re

print(re.sub(r'(([^/]*)(/.*)?)', r'\2.zip/\1/', 'example'))

# Running script at fbb490fd2f38bd817d99c20c05121ad0168a38ee

➜  cpython git:(fbb490fd2f) ./python.exe ../backups/bpo34982.py
example.zip/example/.zip//

# Script at fbb490fd2f38bd817d99c20c05121ad0168a38ee~1

➜  cpython git:(fbb490fd2f) git checkout -q 
fbb490fd2f38bd817d99c20c05121ad0168a38ee~1
➜  cpython git:(0cc99c8cd7) make > /dev/null
➜  cpython git:(0cc99c8cd7) ./python.exe ../backups/bpo34982.py
example.zip/example/

I think is an intended change as noted in the message that might break third 
party code (msg308229) . Adding Serhiy for thoughts.

--

___
Python tracker 

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

[issue34979] Python throws “SyntaxError: Non-UTF-8 code start with \xe8...” when parse source file

[Lu jaymin]

Lu jaymin  added the comment:

Thanks for your suggestions. I will make  a PR on github.

The buffer is resizeable now, please see cpython/Parser/tokenizer.c#L1043

for details.

--

___
Python tracker 

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

[issue6686] xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.property_xml_string) returns bytes

[Jonathan Gossage]

Jonathan Gossage  added the comment:

The other thing to consider which also supports option 2 is that 
xml.parsers.expat provides an interface to the Expat parser which is easier to 
use and more complete than the Sax parser implementation and is the 
implementation likely to be used by anyone needing a streaming parser.

--

___
Python tracker 

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

[issue34982] re.sub() different behavior in 3.7

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue34982] re.sub() different behavior in 3.7

[purificant]

New submission from purificant :

A call to re.sub() returns different results in Python 3.7 compared to versions 
3.6 / 3.5 and 2.7

Example behavior in 2.7 / 3.5 and 3.6:
>>> re.sub(r'(([^/]*)(/.*)?)', r'\2.zip/\1/', 'example')
'example.zip/example/'

Example in 3.7.0 and 3.7.1rc2:
>>> re.sub(r'(([^/]*)(/.*)?)', r'\2.zip/\1/', 'example')
'example.zip/example/.zip//'

As you can see the returned string is different for the same regex. re.subn() 
confirms that 2 replacements are made instead of 1.

Is it intended to have different behaviour in 3.7+ or is this a bug?
Thanks

--
components: Regular Expressions
messages: 327707
nosy: ezio.melotti, mrabarnett, purificant
priority: normal
severity: normal
status: open
title: re.sub() different behavior in 3.7
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue34979] Python throws “SyntaxError: Non-UTF-8 code start with \xe8...” when parse source file

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks for the confirmation. I think the expected solution is to use a buffer 
that can be resized. CPython accepts GitHub PRs so if you have time then I 
would suggest raising a PR against the linked issue since a lot of people have 
subscribed there and would get a good feedback.

As a suggestion when you reply from email please remove the quoted content 
since it makes the message very long and hard to read in the bug tracker.

--

___
Python tracker 

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

[issue34912] Update overflow checks in resize_buffer

[Stefan Behnel]

Stefan Behnel  added the comment:

If I understand the code right, "PY_SSIZE_T_MAX/sizeof(Py_UCS4)" would not be 
correct since it would unnecessarily limit the length of ASCII-only unicode 
strings.

I think the initial check avoids the risk of integer overflow in the 
calculations below, so it's not entirely redundant.

--
nosy: +scoder

___
Python tracker 

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

[issue34981] Unable to install Python from web-based installer and executable installer

[Eric V. Smith]

Change by Eric V. Smith :


--
components: +Windows
nosy: +paul.moore, steve.dower, 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

[issue34972] json dump silently converts int keys to string

[Eric V. Smith]

Change by Eric V. Smith :


--
resolution:  -> not a bug

___
Python tracker 

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

[issue34972] json dump silently converts int keys to string

[My-Tien Nguyen]

Change by My-Tien Nguyen :


--
status: open -> closed

___
Python tracker 

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

[issue34981] Unable to install Python from web-based installer and executable installer

[skycraper]

New submission from skycraper :

I have a PC with 2 HDD with 2 Vista OS at each other. One system is old and it 
has Python 3.7 installed and working successfully. The second system is 
new-installed and it has a problems with running web-based installers and 
executable-installer of the latest Python`s version from there: 
https://www.python.org/downloads/windows/ 

So I can run an install from any MSI-package for every version, but 3.5-3.7 
versions don`t have it. When I`m trying to install wb-inst or exe-inst nothing 
happens: no error window, no system lags etc. 

I suppose that this problem connected with Microsoft libraries or extensions. I 
installed all Visual Studio C++ packages, but it didn`t help. 

Could you tell me which components I forgot to intall.

--
components: Installation
messages: 327704
nosy: skycraper
priority: normal
severity: normal
status: open
title: Unable to install Python from web-based installer and executable 
installer
type: crash
versions: Python 3.7

___
Python tracker 

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

[issue34972] json dump silently converts int keys to string

[My-Tien Nguyen]

My-Tien Nguyen  added the comment:

Sure, I can do that, but wanted to propose this regardless. I guess this is a 
disagreement on a language design level.
As a proponent of strong typing I wouldn’t have allowed non-string keys in the 
first place, and if they are allowed I would warn about conversion. This is 
also more aligned with the “explicit is better than implicit” principle.

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

___
Python tracker 

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

[issue34979] Python throws “SyntaxError: Non-UTF-8 code start with \xe8...” when parse source file

[Lu jaymin]

Lu jaymin  added the comment:

I think these two issue is the same issue, and the following is a patch
write by me, hope this patch will help.

```
diff --git a/Parser/tokenizer.c b/Parser/tokenizer.c
index 1af27bf..ba6fb3a 100644
--- a/Parser/tokenizer.c
+++ b/Parser/tokenizer.c
@@ -617,32 +617,21 @@ decoding_fgets(char *s, int size, struct tok_state
*tok)
 if (!check_coding_spec(line, strlen(line), tok, fp_setreadl)) {
 return error_ret(tok);
 }
-}
-#ifndef PGEN
-/* The default encoding is UTF-8, so make sure we don't have any
-   non-UTF-8 sequences in it. */
-if (line && !tok->encoding) {
-unsigned char *c;
-int length;
-printf("[DEBUG] - [decoding_fgets]: line = %s\n", line);
-for (c = (unsigned char *)line; *c; c += length)
-if (!(length = valid_utf8(c))) {
-badchar = *c;
-break;
+if(!tok->encoding){
+char* cs = new_string("utf-8", 5, tok);
+int r = fp_setreadl(tok, cs);
+if (r) {
+tok->encoding = cs;
+tok->decoding_state = STATE_NORMAL;
+} else {
+PyErr_Format(PyExc_SyntaxError,
+ "You did not decalre the file encoding at the
top of the file, "
+ "and we found that the file is not encoding
by utf-8,"
+ "see http://python.org/dev/peps/pep-0263/ for
details.");
+PyMem_FREE(cs);
 }
+}
 }
-if (badchar) {
-/* Need to add 1 to the line number, since this line
-   has not been counted, yet.  */
-PyErr_Format(PyExc_SyntaxError,
-"Non-UTF-8 code starting with '\\x%.2x' "
-"in file %U on line %i, "
-"but no encoding declared; "
-"see http://python.org/dev/peps/pep-0263/ for details",
-badchar, tok->filename, tok->lineno + 1);
-return error_ret(tok);
-}
-#endif
 return line;
 }
```

by the way, my platform is macOS Mojave Version 10.14

Karthikeyan Singaravelan  于2018年10月14日周日 下午5:10写道：

>
> Karthikeyan Singaravelan  added the comment:
>
> Got it. Thanks for the details and patience. I tested with less number of
> characters and it seems to work fine so using the encoding at the top is
> not a good way to test the original issue as you have mentioned. Then I
> searched around and found issue14811 with test. This seems to be a very
> similar issue and there is a patch to detect this scenario to throw
> SyntaxError that the line is longer than the internal buffer instead of an
> encoding related error. I applied the patch to master and it throws an
> error about the internal buffer length as expected. But the patch was not
> applied and it seems Victor had another solution in mind as per msg167154.
> I tested with the patch as below :
>
> # master
>
> ➜  cpython git:(master) cat ../backups/bpo34979.py
>
> s =
> '测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试'
>
> print("str len : ", len(s))
> print("bytes len : ", len(s.encode('utf-8')))
> ➜  cpython git:(master) ./python.exe ../backups/bpo34979.py
>   File "../backups/bpo34979.py", line 2
> SyntaxError: Non-UTF-8 code starting with '\xe8' in file
> ../backups/bpo34979.py on line 2, but no encoding declared; see
> http://python.org/dev/peps/pep-0263/ for details
>
>
> # Applying the patch file from issue14811
>
> ➜  cpython git:(master) ✗ ./python.exe ../backups/bpo34979.py
>   File "../backups/bpo34979.py", line 2
> SyntaxError: Line 2 of file ../backups/bpo34979.py is longer than the
> internal buffer (1024)
>
> # Patch on master
>
> diff --git a/Parser/tokenizer.c b/Parser/tokenizer.c
> index fc75bae537..48b3ac0ee9 100644
> --- a/Parser/tokenizer.c
> +++ b/Parser/tokenizer.c
> @@ -586,6 +586,7 @@ static char *
>  decoding_fgets(char *s, int size, struct tok_state *tok)
>  {
>  char *line = NULL;
> +size_t len;
>  int badchar = 0;
>  for (;;) {
>  if (tok->decoding_state == STATE_NORMAL) {
> @@ -597,6 +598,15 @@ decoding_fgets(char *s, int size, struct tok_state
> *tok)
>  /* We want a 'raw' read. */
>  line = Py_UniversalNewlineFgets(s, size,
>  tok->fp, NULL);
> +   if (line != NULL) {
> +len = strlen(line);
> +if (1 < len && line[len-1] != '\n') {
> +PyErr_Format(PyExc_SyntaxError,
> +"Line %i of file %U is longer than the
> internal buffer (%i)",
> +tok->lineno + 1, tok->filename, size);
> + 

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

[Mario]

Mario  added the comment:

On 13/10/2018 17:37, Steve Dower wrote:
> 
> Steve Dower  added the comment:
> 
> I meant why are you using an embedded application with a virtual environment? 
> What sort of application do you have that requires users to configure a 
> virtual environment, rather than providing its own set of libraries?
> 
> The embedding scenarios I'm aware of almost always want privacy/isolation 
> from whatever a user has installed/configured, so that they can work reliably 
> even when users modify other parts of their own system. I'm trying to 
> understand what scenario (other than "I am an interactive Python shell") 
> would want to automatically pick up the configuration rather than having its 
> own configuration files/settings.

Does it really matter who owns main(), whether it is in python.exe or in some 
other C app.

This is exactly how you described, users want to use some C application which 
will call into python 
using some (user defined) python modules to execute some tasks which are 
scriptable.
And they want to be able to do in a confined environment where they can install 
the exact set of 
packages they require. And it is possible at the same time to set up multiple 
environments where 
different versions are tested independently.

There is as well the totally independent scenario where the app ships exactly 
what it needs, but 
there are some ways in between where one can script an app and in doing so you 
might need packages 
that the app itself knew nothing about.

For another example have a look at JEP
https://github.com/ninia/jep/search?q=virtual_q=virtual

This is a way to call python from Java: same problem above, people might want 
to run it in a virtual 
environment and the only way to do this now is to manually set up PYTHONHOME, 
but it is pretty weak 
and does not replicate exactly what happens with virtual environments (e.g. 
inherit system's 
site-packages).

Again, in Linux, JEP works out of the box with no need to tell it about virtual 
environments, 
Py_Initialise() finds it (if they are indeed present) with absolutely no extra 
configuration (no 
need to change PYTHONPATH).

Andrea

--

___
Python tracker 

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

[issue6686] xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.property_xml_string) returns bytes

[Tal Einat]

Tal Einat  added the comment:

See additional research and discussion in the comments of PR GH-9715.

Simply changing this to return a string rather than bytes would break backwards 
compatibility.

I certainly agree that this should have returned a string in the first place, 
especially since the Unicode decoding is otherwise completely abstracted away 
and the encoding used is not made available.

Our options:

1. Return a string starting with 3.8, document the change in What's New & fix 
the docs for older 3.x.
2. Continue returning bytes, update the docs for all 3.x that this returns 
bytes, and that there's no good way to know the proper encoding to use for 
decoding it.
3. As 2 above, but also expose the encoding used.

Since this appears to be rarely used and option 3 requires significantly more 
effort than the others, I am against it. 

Option 2 seems the safest, but I'd like to hear more from those more 
experienced with XML.

--
nosy: +Jonathan.Gossage, taleinat
versions: +Python 3.6, Python 3.7, Python 3.8 -Python 3.1

___
Python tracker 

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

[issue34979] Python throws “SyntaxError: Non-UTF-8 code start with \xe8...” when parse source file

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Got it. Thanks for the details and patience. I tested with less number of 
characters and it seems to work fine so using the encoding at the top is not a 
good way to test the original issue as you have mentioned. Then I searched 
around and found issue14811 with test. This seems to be a very similar issue 
and there is a patch to detect this scenario to throw SyntaxError that the line 
is longer than the internal buffer instead of an encoding related error. I 
applied the patch to master and it throws an error about the internal buffer 
length as expected. But the patch was not applied and it seems Victor had 
another solution in mind as per msg167154. I tested with the patch as below : 

# master

➜  cpython git:(master) cat ../backups/bpo34979.py

s = 
'测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试'

print("str len : ", len(s))
print("bytes len : ", len(s.encode('utf-8')))
➜  cpython git:(master) ./python.exe ../backups/bpo34979.py
  File "../backups/bpo34979.py", line 2
SyntaxError: Non-UTF-8 code starting with '\xe8' in file ../backups/bpo34979.py 
on line 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ 
for details


# Applying the patch file from issue14811

➜  cpython git:(master) ✗ ./python.exe ../backups/bpo34979.py
  File "../backups/bpo34979.py", line 2
SyntaxError: Line 2 of file ../backups/bpo34979.py is longer than the internal 
buffer (1024)

# Patch on master

diff --git a/Parser/tokenizer.c b/Parser/tokenizer.c
index fc75bae537..48b3ac0ee9 100644
--- a/Parser/tokenizer.c
+++ b/Parser/tokenizer.c
@@ -586,6 +586,7 @@ static char *
 decoding_fgets(char *s, int size, struct tok_state *tok)
 {
 char *line = NULL;
+size_t len;
 int badchar = 0;
 for (;;) {
 if (tok->decoding_state == STATE_NORMAL) {
@@ -597,6 +598,15 @@ decoding_fgets(char *s, int size, struct tok_state *tok)
 /* We want a 'raw' read. */
 line = Py_UniversalNewlineFgets(s, size,
 tok->fp, NULL);
+   if (line != NULL) {
+len = strlen(line);
+if (1 < len && line[len-1] != '\n') {
+PyErr_Format(PyExc_SyntaxError,
+"Line %i of file %U is longer than the internal 
buffer (%i)",
+tok->lineno + 1, tok->filename, size);
+return error_ret(tok);
+}
+}
 break;
 } else {
 /* We have not yet determined the encoding.


If it's the same issue then I think closing this issue and discussing there 
will be good since the issue has a patch with test and relevant discussion. 
Also it seems BUFSIZ is platform dependent so adding your platform details 
would also help.

TIL about difference Python 2 and 3 on handling unicode related files. Thanks 
again!

--

___
Python tracker 

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

[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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

[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 7c1c42b3209f1d2546daab6cd77f953eb255df6c by Serhiy Storchaka in 
branch '3.6':
[3.6] bpo-34941: Fix searching Element subclasses. (GH-9766) (GH-9868)
https://github.com/python/cpython/commit/7c1c42b3209f1d2546daab6cd77f953eb255df6c


--

___
Python tracker 

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

[issue34979] Python throws “SyntaxError: Non-UTF-8 code start with \xe8...” when parse source file

[Lu jaymin]

Lu jaymin  added the comment:

If you declare the encoding at the top of the file, then everything is
fine, because in this case Python will use `io.open` to open the file and
use `stream.readline` to read one line of code, please see function
`fp_setreadl` in `cpython/Parser/tokenizer.c` for detail.

But if you did not declare the encoding, then Python will use
`Py_UniversalNewlineFgets` to read one line of raw bytes and check these
raw bytes's encoding by `valid_utf8`.

In my opinion, when the encoding of the file is utf-8, and because the
default file encoding of Python3 is utf-8, so whether we declare encoding
or did not is ok.

Karthikeyan Singaravelan  于2018年10月14日周日 下午1:06写道：

>
> Karthikeyan Singaravelan  added the comment:
>
> Thanks for the report. Is this a case of encoding not being declared at
> the top of the file or am I missing something?
>
> ➜  cpython git:(master) cat ../backups/bpo34979.py
> s =
> '测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试'
>
> print("str len : ", len(s))
> print("bytes len : ", len(s.encode('utf-8')))
> ➜  cpython git:(master) ./python.exe ../backups/bpo34979.py
>   File "../backups/bpo34979.py", line 1
> SyntaxError: Non-UTF-8 code starting with '\xe8' in file
> ../backups/bpo34979.py on line 1, but no encoding declared; see
> http://python.org/dev/peps/pep-0263/ for details
>
> # With encoding declared
>
> ➜  cpython git:(master) cat ../backups/bpo34979.py
> # -*- coding: utf-8 -*-
>
> s =
> '测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试'
>
> print("str len : ", len(s))
> print("bytes len : ", len(s.encode('utf-8')))
> ➜  cpython git:(master) ./python.exe ../backups/bpo34979.py
> str len :  340
> bytes len :  1020
>
> # Double the original string
>
> ➜  cpython git:(master) cat ../backups/bpo34979.py
> # -*- coding: utf-8 -*-
>
> s =
> '测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试测试'
>
> print("str len : ", len(s))
> print("bytes len : ", len(s.encode('utf-8')))
> ➜  cpython git:(master) ./python.exe ../backups/bpo34979.py
> str len :  680
> bytes len :  2040
>
>
> Thanks
>
> --
> nosy: +xtreak
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

Re: Python indentation (3 spaces)

[Peter J. Holzer]

On 2018-10-14 00:45:49 +, Grant Edwards wrote:
> On 2018-10-13, Peter J. Holzer  wrote:
> >
> >> For "just use tabs" to work, all of those tools would have to
> >> magically recognize that they're looking at Python source and adjust
> >> the tab size accordingly.  That isn't going to happen.
> >
> > Well, no. The idea of "just use tabs" isn't have a different tab width
> > per language, but a different tab width per user.
> 
> You work in a different environment than I do.  for me, tab width
> varies from one project to another (sometimes even in the same
> language).  I don't get to pick just one tab width.

You probably don't because you use spaces, not tabs.

If everybody used tabs, why would anyone care about your tab width?
Unless they look over your shoulder while you are typing, they won't
even know how wide your tabs are.

(That said, I personally prefer shorter indentation for marked up text
(like HTML or LaTeX) than for programming languages. But I could live
with the same indentation if necessary (and of course it isn't
necessary: Any decent editor has to be able detect the file type anyway
for syntax highlighting so it can adjust the display of tabs, too.))

hp

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


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

[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder

[miss-islington]

miss-islington  added the comment:


New changeset b1c800303e8458e00428ae66351ad492a503a46f by Miss Islington (bot) 
in branch '3.7':
bpo-34941: Fix searching Element subclasses. (GH-9766)
https://github.com/python/cpython/commit/b1c800303e8458e00428ae66351ad492a503a46f


--
nosy: +miss-islington

___
Python tracker 

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

[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +9236

___
Python tracker 

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

Re: Python indentation (3 spaces)

[Christian Gollwitzer]

Am 14.10.18 um 02:45 schrieb Grant Edwards:

On 2018-10-13, Peter J. Holzer  wrote:



For "just use tabs" to work, all of those tools would have to
magically recognize that they're looking at Python source and adjust
the tab size accordingly.  That isn't going to happen.


Well, no. The idea of "just use tabs" isn't have a different tab width
per language, but a different tab width per user.


You work in a different environment than I do.  for me, tab width
varies from one project to another (sometimes even in the same
language).  I don't get to pick just one tab width.


But if you use only tabs for indentation, the tab width setting simply 
does not matter. I'm in favour of using only tabs.


There is a disadvantage only if you try to align something which is NOT 
an indentation level, e.g. when there are big string constants or list 
constants etc.


Christian


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

[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder

[miss-islington]

Change by miss-islington :


--
pull_requests: +9235

___
Python tracker 

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

[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset b11c5667f99c4f0018e3394c4d07c519d835671a by Serhiy Storchaka in 
branch 'master':
bpo-34941: Fix searching Element subclasses. (GH-9766)
https://github.com/python/cpython/commit/b11c5667f99c4f0018e3394c4d07c519d835671a


--

___
Python tracker 

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

[issue34980] KillPython target doesn't detect 64-bit processes

[Jeremy Kloth]

New submission from Jeremy Kloth :

Since the KillPython target has been rewritten as an InlineTask, it can no 
longer detect 64-bit processes due to MSBuild being 32-bit.

This leads to stuck buildbot runs:
  https://buildbot.python.org/all/#/builders/17/builds/348

A few solutions that I can think of:

1) Switch the InlineTask to an Exec using a PowerShell script to kill the 
processes.
   In my limited testing, PowerShell is installed by default on the supported 
OSes (Win7+).

   

2) When building for platform x64, modify find_msbuild.bat to locate the 64-bit 
MSBuild executable

3) On 64-bit OS, always use the 64-bit MSBuild executable

4) Only use the 64-bit MSBuild (when available) for the KillPython target (the 
64-bit KillPython target can detect 32-bit processes)

I am unsure of any issues that may arise from building with the 64-bit MSBuild 
toolchain.

--
components: Build, Windows
messages: 327694
nosy: jkloth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: KillPython target doesn't detect 64-bit processes
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue34968] loop.call_soon_threadsafe should be documented to be re-entrant-safe too

[Nathaniel Smith]

Nathaniel Smith  added the comment:

> What would make it not reentrant-safe?

Probably the most obvious example of a non-reentrant-safe operation is taking a 
lock. It's very natural to write code like:

def call_soon(...):
with self._call_soon_lock:
...

but now imagine that inside the body of that 'with' statement, a signal 
arrives, so the interpreter pauses what it's doing to invoke the signal 
handler, and the signal handler turns around and invokes call_soon, which tries 
to acquire the same lock that it already holds → instant deadlock.

And this rules out quite a few of the tools you might normally expect to use in 
thread-safe code, like queue.Queue, since they use locks internally.

The reason I think the stdlib's call_soon is OK is that it doesn't perform any 
blocking operations, and the critical operation is simply 
'self._ready.append(...)', which in CPython is atomic with respect to 
threads/signals/GC.

--

___
Python tracker 

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

[issue34927] Tkinter-related segfault on macOS (regression between 3.7.0 and 3.7.1rc1)

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks for the release Ned. I can confirm that there is no segfault with Python 
3.7.1rc2 (v3.7.1rc2:6c06ef7dc3).

--

___
Python tracker 

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

[issue34977] Release Windows Store app containing Python

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

+1 for reliable installation. There were some cases (issue33220, issue30944) 
where the installer was detected as a Virus by some vendors which would be 
reduced since this is installed from the App store as a verified app. I hope 
this will also reduce the scenarios where users need to resort to bug tracker 
with log files when there are installation failures [1] providing a more smooth 
one click install.

There is a long standing open issue [2] to make `pip install --user` as a 
default which I hope gets resolved and there is an issue with using `pip 
install --user` inside a virtualenv which seems to block the earlier issue [3]

Thanks a lot for this!

[1] 
https://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid=file%3Acontent&%40search_text=windows+msi+install=search=-1%2C1%2C2%2C3

[2] https://github.com/pypa/pip/issues/1668

[3] https://github.com/pypa/pip/issues/5702

--
nosy: +xtreak

___
Python tracker 

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