[issue31555] Windows pyd slower when not loaded via load_dynamic

[Safihre]

Change by Safihre :


--
resolution: third party -> 

___
Python tracker 

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

[issue31555] Windows pyd slower when not loaded via load_dynamic

[Safihre]

Safihre  added the comment:

No, the difference is not wheel vs setuptools. They both generate the identical 
pyd file. 
The difference is python: if the module is loaded by just being available on 
the path or if the module is loaded via  imp.load_dynamic

I understand if it's closed because it's not python 3, but it's not external 
tool related.

--
status: closed -> open

___
Python tracker 

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

[issue31646] bug in time.mktime

[Kadir Liano]

Kadir Liano  added the comment:

time.mktime(time.strptime('09-Mar-14 01:00:00',fmt))
time.mktime(time.strptime('09-Mar-14 02:00:00',fmt))

Both statements produce 1394348400.0 in Win7.  The answers are 1394348400.0 and 
1394352000.0 in Linux which is the correct behavior.

--

___
Python tracker 

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

[issue31647] asyncio: StreamWriter write_eof() after close raises mysterious AttributeError

[twisteroid ambassador]

twisteroid ambassador  added the comment:

This issue is somewhat related to issue27223, in that both are caused by using 
self._sock after it has already been assigned None when the connection is 
closed. It seems like Transports in general may need better protection from 
this kind of behavior.

--

___
Python tracker 

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

[issue31647] asyncio: StreamWriter write_eof() after close raises mysterious AttributeError

[twisteroid ambassador]

New submission from twisteroid ambassador :

Currently, if one attempts to do write_eof() on a StreamWriter after the 
underlying transport is already closed, an AttributeError is raised:


Traceback (most recent call last):
  File "\scratch_3.py", line 34, in main_coro
writer.write_eof()
  File "C:\Program Files\Python36\lib\asyncio\streams.py", line 300, in 
write_eof
return self._transport.write_eof()
  File "C:\Program Files\Python36\lib\asyncio\selector_events.py", line 808, in 
write_eof
self._sock.shutdown(socket.SHUT_WR)
AttributeError: 'NoneType' object has no attribute 'shutdown'


This is because _SelectorSocketTransport.write_eof() only checks for self._eof 
before calling self._sock.shutdown(), and self._sock has already been assigned 
None after _call_connection_lost().

Compare with StreamWriter.write() after close, which either does nothing or 
logs a warning after 5 attempts; or StreamWriter.drain() after close, which 
raises a ConnectionResetError; or even StreamWriter.close() after close, which 
does nothing.

Trying to do write_eof() after close may happen unintentionally, for example 
when the following sequence of events happen:
* the remote side closes the connection
* the local side attempts to write, so the socket "figures out" the connection 
is closed, and close this side of the socket. Note the write fails silently, 
except when loop.set_debug(True) where asyncio logs "Fatal write error on 
socket transport".
* the local side does write_eof(). An AttributError is raised.

Currently the only way to handle this gracefully is to either catch 
AttributeError or check StreamWriter.transport.is_closing() before write_eof(). 
Neither is pretty.

I suggest making write_eof() after close either do nothing, or raise a subclass 
of ConnectionError. Both will be easier to handle then the current behavior.

Attached repro.

--
components: asyncio
files: asyncio_write_eof_after_close_test.py
messages: 303391
nosy: twisteroid ambassador, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: StreamWriter write_eof() after close raises mysterious 
AttributeError
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: 
https://bugs.python.org/file47180/asyncio_write_eof_after_close_test.py

___
Python tracker 

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

[issue31646] bug in time.mktime

[Eryk Sun]

Eryk Sun  added the comment:

mktime() is the inverse of localtime(). With the given format string, 
strptime() sets tm_isdst to -1, for which mktime will use the system's timezone 
information to determine whether or not it's daylight saving time. You need to 
verify that the time zones are the same. 

For me the results agree in Linux and Windows with the local timezone on both 
systems set to the UK.

9 March (GMT, standard time)

Linux
>>> time.mktime(time.struct_time((2014, 3, 9, 2, 0, 0, 6, 68, 0)))
1394330400.0
>>> time.mktime(time.struct_time((2014, 3, 9, 2, 0, 0, 6, 68, -1)))
1394330400.0

Windows
>>> time.mktime(time.struct_time((2014, 3, 9, 2, 0, 0, 6, 68, 0)))
1394330400.0
>>> time.mktime(time.struct_time((2014, 3, 9, 2, 0, 0, 6, 68, -1)))
1394330400.0

9 August (BST, daylight saving time)

Linux
>>> time.mktime(time.struct_time((2014, 8, 9, 2, 0, 0, 6, 68, 1)))
1407546000.0
>>> time.mktime(time.struct_time((2014, 8, 9, 2, 0, 0, 6, 68, -1)))
1407546000.0

Windows
>>> time.mktime(time.struct_time((2014, 8, 9, 2, 0, 0, 6, 68, 1)))
1407546000.0
>>> time.mktime(time.struct_time((2014, 8, 9, 2, 0, 0, 6, 68, -1)))
1407546000.0

--
nosy: +eryksun

___
Python tracker 

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

[issue26259] Memleak when repeated calls to asyncio.queue.Queue.get is performed, without push to queue.

[Suren Nihalani]

Suren Nihalani  added the comment:

@cjrh brought up that this issue is the same as 
https://bugs.python.org/issue31620. I put up a PR there. Can people review that 
and then we can close this?

--
nosy: +snihalani

___
Python tracker 

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

Distributing multiple packages with on setup.py

[Jimmy Thrasibule]

Hi,

I've reorganized my Python project to be under a same name umbrella.
My project can now be seen as multiple subsystems than can depend on
each other. That means that every sub-package can now be distributed
alone so that only required dependencies can be installed.

The old structure:


/
├─ myproj/
│  ├─ __init__.py
│  ├─ mod1.py
│  ├─ subpackage1/
│  └─ subpackage2/
└─ setup.py


The new structure:


/
├─ myproj/
│  ├─ common/
│  │  └─ mod1.py
│  ├─ subpackage1/
│  ├─ subpackage2/
│  └─ __init__.py
└─ setup.py


As you can see not much has changed except that `myproj` is now a
`namespace package
`_
and that sub-packages ``common``, ``subpackage1`` and ``subpackage2``
can now be distributed independently.

Is it possible, still keeping one unique ``setup.py`` file, to create
3 independent packages?

* ``myproj.common``
* ``myproj.subpackage1``
* ``myproj.subpackage2``

Also I'd like to specify that when installing ``myproj.subpackage1``,
``myproj.common`` is required or that ``myproj.subpackage2`` will
require both ``myproj.common`` and ``myproj.subpackage1``.

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

The mysterious ways of Python mailing list

[Vincent Vande Vyvre]

Is it a reason why my messages appears always a long time (today 9 
hours) on the list after I send it ?


Send at 19:14 UTC+2


Vincent

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

[issue31590] CSV module incorrectly treats escaped newlines as new records if unquoted

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I explained on #15927 why I currently see it as an enhancement issue, and 
therefore not appropriate to be backported.  In fact, based on the doc, I am 
puzzled why the line terminator was being escaped.

--

___
Python tracker 

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

[issue15927] csv.reader() does not support escaped newline when quoting=csv.QUOTE_NONE

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This issue was 'reopened' by #31590.

I can understand inconsistency as a 'design bug', but design bugs are not code 
bugs, and fixing a design bugs is an enhancement issue, not a behavior issue.

It is not clear to me why, with the specified dialect,  
"writer.writerow(['one\nelement'])" is correct in writing 'one\\\nelement\n'.  
The doc for Dialect.excapechar says "A one-character string used by the writer 
to escape the delimiter if quoting is set to QUOTE_NONE and the quotechar if 
doublequote is False."  Yes, quoting is set to QUOTE_NONE, but \n is the 
lineterminator, not the delimiter (or the quotechar).  It looks to me that 
escaping the lineterminator might be a bug.

In any case, 'one\nelement' and 'one\\\nelement' are each 2 physical lines.  I 
don't see anything in the doc about csv.reader joining physical lines into 
'logical' lines the way that compile() does.

--
nosy: +terry.reedy

___
Python tracker 

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

Re: Beginners and experts (Batchelder blog post)

[justin walters]

On Fri, Sep 29, 2017 at 12:14 PM, Bill  wrote:

>
> I'll write for the possible benefit of any beginners who may be reading.
> I guess by definition, if one still has a "bug" it's because one doesn't
> quite understand what the code is doing. And I would say you should lose
> your license if you "fix something", and don't understand why it works
> (within reason of course--some mystery's of library functions should
> probably remain so forever). So ADT (Any Damn Thing--I just made that up
> that acronym) you can do to understand your code better is fair game! : )
>   In fact, in my experience, the sooner you start getting a little bit
> angry, the sooner you'll get to the heart of matter.  Usually, what looks
> like a long route, isn't, in the end.  Don't be afraid to write *really
> descriptive* output statements, and do so even though you "don't need to".
> Besides for making you more productive, it will help soothe you : )
>  Beginners almost never need to...  I think that getting out of the
> beginner phase requires developing a certain amount of humility.  Just wait
> 5 or 10 years, any look back, and see if what I've written isn't more true
> than false.
>
> The only part I am unsure of is whether you are supposed to get a little
> big angry or not (YMMV).  I find 2 cups of coffee about right. That is, 2
> before and 2 after lunch. Of course, that does not include "meetings".
> --
> https://mail.python.org/mailman/listinfo/python-list
>

Reminds me of a bug I had to chase down recently.

I've been working on the front-end of this web application for a while.
It's an SPA built
with Vuejs. The bug arose in the login workflow. Basically, it went like
this:

client loads login screen -> user enters credentials into form and submits
-> client sends credentials to server ->
server verifies credentials -> server sends back auth token -> client
receives auth token and stores it ->
client redirects user to home screen -> home screen makes get request for
some data

Now, this worked perfectly fine everywhere except for Safari 9.1 on OSX.

A user could login just fine on Safari 9.1, but after that, no requests
would complete. Safari's dev tools
were no help because they were not showing any errors or any failed
requests. I checked the server logs
and found that no requests were even sent.

It took me 2 days to figure out this bug. I tracked it down to the function
that injected the authorization
header into all requests if the user was logged in. Based on
troubleshooting, I knew it couldn't be anything else.
That said, I was still confused because this worked on literally every
other browser(even IE 9).

After searching for people with similar problems and coming up with nothing
I got to thinking about the
asynchronous nature of JS. So, out of sheer frustration I moved the line of
code that stored the auth token
from one function to another, booted up my testing environment, and it
worked.

So, the bug was basically because Safari was waiting for a specific
function call to complete before
it committed the token to local storage even though the line of code that
did so was within said function.

So, two days worth of work to move a single line of code from one function
to another. You can only imagine
the tirade of curse words directed at apple during the above calamity.

Had I simply written a console log for every function down the chain, I may
have been able to find the
cause of the bug more quickly.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31601] Availability of utimensat, futimens not checked correctly on macOS

[Ronald Oussoren]

Ronald Oussoren  added the comment:

This is true for other symbols as well, when deploying to older releases of 
macOS. 

I have added runtime checking for a number of symbols in the past, that could 
be extended to newer APIs.  

--
On the road, hence brief. 

Op 30 sep. 2017 om 09:17 heeft Terry J. Reedy  het 
volgende geschreven:

> 
> Change by Terry J. Reedy :
> 
> 
> --
> components: +macOS
> nosy: +ned.deily, ronaldoussoren
> title: Availability of utimensat and futimens not checked correctly on macOS 
> -> Availability of utimensat,futimens not checked correctly on macOS
> 
> ___
> Python tracker 
> 
> ___

--
title: Availability of utimensat,futimens not checked correctly on macOS -> 
Availability of utimensat, futimens not checked correctly on macOS

___
Python tracker 

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

Re: Beginners and experts (Batchelder blog post)

[Gregory Ewing]

Bill wrote:
Don't be afraid to write *really descriptive* output statements, and do 
so even though you "don't need to".


Yeah, often when I'm writing something tricky I'll proactively
put in some code to print intermediate state to reassure myself
that things are on track. Being more verbose with them than I
think necessary can save a few trips around the debug cycle.

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

[issue31644] bug in datetime.datetime.timestamp

[Kadir Liano]

Kadir Liano  added the comment:

The datetime object returned by strptime() does not have tzinfo.  Whatever 
default timezone that was chosen should produce consistent timestamp.  Reading 
a sequential datetime string and converting it to a sequence of timestamp 
results in expected time folding.

datetime.datetime.strptime(dtstr,fmt).timestamp()

--

___
Python tracker 

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

Re: Beginners and experts (Batchelder blog post)

[Gregory Ewing]

Steve D'Aprano wrote:

(1) I know there's a bug in a specific chunk of code, but I'm having trouble
working out where. When everything else fails, if I perturb the code a bit
(reorder lines, calculate things in a different order, rename variables, etc)
it may change the nature of the bug enough for me to understand what's
happening.


> Its an experiment, but not really "carefully designed".

I think it's more carefully designed than you give it credit for.
You still need to understand quite a lot about the program to know
what changes are likely to yield useful information, and how to
interpret the results.


Its more like "what
happens if we hit this bit with a hammer?"


In biology it's called a "shotgun experiment". "If we blast this
bit of DNA with radiation, what part of the organism does it
mess up?"


(2) I hate off by one errors, and similar finicky errors that mean your code is
*almost* right. I especially hate them when I'm not sure which direction I'm
off by one. If you have unit tests that are failing, sometimes its quicker and
easier to randomly perturb the specific piece of code until you get the right
answer, rather than trying to analyse it.


With off-by-one errors it's still pretty specific -- start
the loop at 1 instead of 0, etc.

But in cases like that I prefer to rewrite the code so that
it's obvious where it should start and finish.


The complexity of code increases faster than our ability to manage that
complexity.


And then there's "If you write the code as cleverly as you can,
you won't be smart enough to debug it!"

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

[issue31623] Allow to build MSI installer from the official tarball

[Terry J. Reedy]

Change by Terry J. Reedy :


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

[issue31613] Localize tkinter.simpledialog.Default buttons as with file dialogs.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I would make such new paremeters keyword-only.

--

___
Python tracker 

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

[issue31613] Localize tkinter.simpledialog.Default buttons as with file dialogs.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Tkinter wraps the tcl/tk gui framework.  The file dialogs and messageboxes are 
provided by tk.  When possible, the file dialogs utilize the native OS file 
dialogs.  The localization is done the by the OS. If the messageboxes are 
localized, then I presume the same is true of them also.

tkinter.simpledialog is a tkinter add-on module written in Python, using tk 
widgets.  SimpleDialog does not have default buttons; they must be supplied in 
the initialization call.  Dialog does provide default *example* buttons.  The 
docstring says "override if you do not want the standard buttons".  

Tk does not provide localized [Ok] and [Cancel] buttons.  AFAIK, Python does 
not provide access to the OS local translations. You will have to provide 
localization yourself.

A reasonable enhancement request might be to add "ok='OK', cancel='Cancel'" to 
the signature of Dialog.__init__ so that a user could pass in local 
translations. These would then be passed on to buttonbox, to be used instead of 
the current hard-coded strings.

--
nosy: +terry.reedy
title: tkinter.simpledialog default buttons (not buttonbox) are not localized, 
unlike all messagebox -> Localize tkinter.simpledialog.Default buttons as with 
file dialogs.
type: behavior -> enhancement
versions: +Python 3.7 -Python 3.5

___
Python tracker 

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

[issue31590] CSV module incorrectly treats escaped newlines as new records if unquoted

[Vaibhav Mallya (mallyvai)]

Vaibhav Mallya (mallyvai)  added the comment:

If there's any way this can be documented that would be a big help, at
least. There have been other folks who run into this, and the current
behavior is implicit.

On Sep 29, 2017 5:44 PM, "R. David Murray"  wrote:

R. David Murray  added the comment:

I'm pretty hesitant to make this kind of change in python2.  I'm going to
punt, and let someone else make the decision.  Which means if no one does,
the status quo will win.  Sorry about that.

--

___
Python tracker 

___

--
nosy: +Vaibhav Mallya (mallyvai)

___
Python tracker 

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

[issue31590] CSV module incorrectly treats escaped newlines as new records if unquoted

[R. David Murray]

R. David Murray  added the comment:

I'm pretty hesitant to make this kind of change in python2.  I'm going to punt, 
and let someone else make the decision.  Which means if no one does, the status 
quo will win.  Sorry about that.

--

___
Python tracker 

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

[issue31644] bug in datetime.datetime.timestamp

[Eric V. Smith]

Eric V. Smith  added the comment:

This is a daylight savings time folding problem. Without a timezone, those are 
in fact the same point in time, at least in my timezone (US Eastern).

If you specify a timezone, you'll see the difference:

datetime.datetime(2014,3,9,2,tzinfo=datetime.timezone(datetime.timedelta(0))).timestamp()
 -> 1394330400.0

datetime.datetime(2014,3,9,3,tzinfo=datetime.timezone(datetime.timedelta(0))).timestamp()
 -> 1394334000.0

These are 3600 seconds, or one hour, apart.

--
nosy: +eric.smith
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

[issue30576] http.server should support HTTP compression (gzip)

[Martin Panter]

Martin Panter  added the comment:

Regarding the compressed data generator, it would be better if there were no 
restrictions on the generator yielding empty chunks. This would match how the 
upload “body” parameter for HTTPConnection.request can be an iterator without 
worrying about empty chunks. IMO a chunked encoder should skip empty chunks and 
add the trailer itself, rather than exposing these special requirements to 
higher levels.

--

___
Python tracker 

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

[issue31646] bug in time.mktime

[Kadir Liano]

New submission from Kadir Liano :

import time
fmt = '%d-%b-%y %H:%M:%S'
print(time.mktime(time.strptime('09-Mar-14 02:00:00',fmt)))

1394348400.0 in Windows 7, Python 2.7 and 3.6
1394352000.0 in LinuxMint LMDE 2, Python 3.6

--
components: Library (Lib)
messages: 303378
nosy: kliano
priority: normal
severity: normal
status: open
title: bug in time.mktime
type: behavior

___
Python tracker 

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

[issue31601] Availability of utimensat, futimens not checked correctly on macOS

[Terry J. Reedy]

Change by Terry J. Reedy :


--
components: +macOS
nosy: +ned.deily, ronaldoussoren
title: Availability of utimensat and futimens not checked correctly on macOS -> 
Availability of utimensat,futimens not checked correctly on macOS

___
Python tracker 

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

[issue31594] Make bytes and bytearray maketrans accept dictionaries as first argument as it's done in str

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Consistency between bytes and strings is not much of a concern here, or the 
change would have been make for bytes when it was made for strings.  I would 
not approve the request without knowing who chose not to and why.

I think an example like
t = bytes.maketrans(
b'ABCDEVGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz',
b'vcccvcccvcvcvcscscvcccvcccvcvcvcscsc')
is *much* better as it is than as a dict.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue31590] CSV module incorrectly treats escaped newlines as new records if unquoted

[Terry J. Reedy]

Terry J. Reedy  added the comment:

In closing #15927, R. David Murray said "Although this is clearly a bug fix, it 
also represents a behavior change that could cause a working program to fail.  
I have therefore only applied it to 3.4, but I'm open to arguments that it 
should be backported." 

David, I'll leave you to evaluate the argument presented.

Vaibhav: in the meanwhile, consider moving your pipeline to 3.x or patching 
your copy of the csv module.  You can put it in sitepackes as csv27.  Or if you 
are distributing code anyway, include your patched copy with it.

--
nosy: +r.david.murray, terry.reedy

___
Python tracker 

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

[issue31591] Closing socket raises AttributeError: 'collections.deque' object has no attribute '_decref_socketios'

[Terry J. Reedy]

Terry J. Reedy  added the comment:

reidfaiv: bpo issues are for patching cypthon, including the stdlib and docs.  
Debugging help should be requested on other forums, such as python-list or 
stackoverflow.

On the other hand, segfaults in pure python code that uses *current* python and 
does not use cypes or third party extension modules is of concern to us.  
Because of such concern, there are crash bugs fixed in every new version and 
some maintenance releases.  Upgrading your application from 3.4 to 3.6.3 (or 
soon, 3.7,0) might benefit from the cumulative work and fix your problem.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue31642] None value in sys.modules no longer blocks import

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This is a side effect of issue15767. The exception is raised in _find_and_load, 
but it is always silenced in _handle_fromlist.

--

___
Python tracker 

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

[issue31643] test_uuid: test_getnode and test_windll_getnode fail if connected to the Internet via an Android phone

[Ivan Pozdeev]

Ivan Pozdeev  added the comment:

Example failure:

==
FAIL: test_windll_getnode (test.test_uuid.TestInternals)
--
Traceback (most recent call last):
  File "C:\Ivan\cpython\lib\test\test_uuid.py", line 501, in test_windll_getnode

self.check_node(node)
  File "C:\Ivan\cpython\lib\test\test_uuid.py", line 449, in check_node
"%s is not an RFC 4122 node ID" % hex)
AssertionError: False is not true :  is not an RFC 4122 node ID

==
FAIL: test_getnode (test.test_uuid.TestUUID)
--
Traceback (most recent call last):
  File "C:\Ivan\cpython\lib\test\test_uuid.py", line 296, in test_getnode
self.assertTrue(0 < node1 < (1 << 48), '%012x' % node1)
AssertionError: False is not true : 

--

___
Python tracker 

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

[issue31645] openssl build fails in win32 if .pl extension is not associated with Perl

[Ivan Pozdeev]

Change by Ivan Pozdeev :


--
type:  -> compile error

___
Python tracker 

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

[issue31645] openssl build fails in win32 if .pl extension is not associated with Perl

[Ivan Pozdeev]

New submission from Ivan Pozdeev :

build_ssl.py:fix_makefile() removes "PERL=perl" line from 
externals\openssl-1.0.2j\ms\nt.mak .

This results in lots of calls like:

./util/copy-if-different.pl "" ""

(without the leading "perl")

Which opens the file in the program associates with the extension (Notepad by 
default) instead of executing it.

Since build_ssl.py:main():219 adds the found Perl into PATH, "PERL=perl" should 
be safe in all cases and there's no reason to omit it.

--
components: Build
files: 0001-Fix-openssl-failing-if-.pl-extension-is-not-associat.patch
keywords: patch
messages: 303372
nosy: Ivan.Pozdeev
priority: normal
severity: normal
status: open
title: openssl build fails in win32 if .pl extension is not associated with Perl
versions: Python 3.4
Added file: 
https://bugs.python.org/file47179/0001-Fix-openssl-failing-if-.pl-extension-is-not-associat.patch

___
Python tracker 

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

[issue31620] asyncio.Queue leaks memory if the queue is empty and consumers poll it frequently

[Caleb Hattingh]

Caleb Hattingh  added the comment:

This looks like a dupe, or at least quite closely related to 
https://bugs.python.org/issue26259. If the PR resolves both issues that one 
should be closed too.

--
nosy: +cjrh

___
Python tracker 

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

[issue31555] Windows pyd slower when not loaded via load_dynamic

[Steve Dower]

Steve Dower  added the comment:

The only difference between your two tests is the install tool, and neither 
setuptools nor wheel bugs are tracked here.

--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue31574] Add dtrace hook for importlib

[Łukasz Langa]

Łukasz Langa  added the comment:

Merged. Thanks! ✨  ✨

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

[issue31574] Add dtrace hook for importlib

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 3d2b407da048b14ba6e5eb6079722a785d210590 by Łukasz Langa 
(Christian Heimes) in branch 'master':
bpo-31574: importlib dtrace (#3749)
https://github.com/python/cpython/commit/3d2b407da048b14ba6e5eb6079722a785d210590


--

___
Python tracker 

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

[issue31574] Add dtrace hook for importlib

[Łukasz Langa]

Łukasz Langa  added the comment:

Amazing!

--

___
Python tracker 

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

[issue31583] 2to3 call for file in current directory yields error

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue31581] Reduce the number of imports for functools

[Terry J. Reedy]

Terry J. Reedy  added the comment:

An option for deferred imports would be to leave a comment at the top where the 
import would otherwise be.  Example:

# import types, weakref  # Deferred to single_dispatch()

This accomplishes the PEP8 purpose of making all dependencies of the module 
visible at the top.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue11063] Rework uuid module: lazy initialization and add a new C extension

[Łukasz Langa]

Łukasz Langa  added the comment:

uuid fails to build for me on master since that change landed:


cpython/Modules/_uuidmodule.c:13:11: error: implicit declaration of function 
'uuid_generate_time_safe' is invalid in C99
  [-Werror,-Wimplicit-function-declaration]
res = uuid_generate_time_safe(out);
  ^
cpython/Modules/_uuidmodule.c:13:11: note: did you mean 
'py_uuid_generate_time_safe'?
cpython/Modules/_uuidmodule.c:8:1: note: 'py_uuid_generate_time_safe' declared 
here
py_uuid_generate_time_safe(void)
^
cpython/Modules/_uuidmodule.c:13:11: warning: this function declaration is not 
a prototype [-Wstrict-prototypes]
res = uuid_generate_time_safe(out);
  ^
1 warning and 1 error generated.


This is on macOS Sierra.

--
nosy: +lukasz.langa

___
Python tracker 

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

[issue31557] tarfile: incorrectly treats regular file as directory

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy: +lars.gustaebel

___
Python tracker 

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

[issue31641] concurrent.futures.as_completed() no longer accepts arbitrary iterables

[Łukasz Langa]

Łukasz Langa  added the comment:

Fix is already landed in 3.6 and master.

--

___
Python tracker 

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

[issue31555] Windows pyd slower when not loaded via load_dynamic

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This issue is more likely to get attention if there is a difference in 3.6, or 
even better, 3.7.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue31644] bug in datetime.datetime.timestamp

[Kadir Liano]

New submission from Kadir Liano :

datetime.datetime(2014,3,9,2).timestamp() returns 1394352000.0
datetime.datetime(2014,3,9,3).timestamp() returns 1394352000.0

--
components: Library (Lib)
messages: 303362
nosy: kliano
priority: normal
severity: normal
status: open
title: bug in datetime.datetime.timestamp
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

[issue31641] concurrent.futures.as_completed() no longer accepts arbitrary iterables

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 9ef28b6ad3d5aff767e3d852499def8b5ae5ff5d by Łukasz Langa (Miss 
Islington (bot)) in branch '3.6':
[3.6] bpo-31641: Allow arbitrary iterables in 
`concurrent.futures.as_completed()` (GH-3830) (#3831)
https://github.com/python/cpython/commit/9ef28b6ad3d5aff767e3d852499def8b5ae5ff5d


--

___
Python tracker 

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

[issue31643] test_uuid: test_getnode and test_windll_getnode fail if connected to the Internet via an Android phone

[Ivan Pozdeev]

New submission from Ivan Pozdeev :

Ethernet emulation for some devices like Android phones' tethering use all-zero 
MAC addresses (which is okay since they don't actually pass Ethernet frames to 
other NICs). This results in a node ID of 0 if I'm currently connected to the 
Net via such a device. Which fails range checks in the corresponding tests.

RFC 4122 doesn't actually have any prohibitions of using a node ID of 0. 
Neither does IEEE 802.3 (or rather, whatever info I gathered on it since the 
standard's text is not freely available) assign any special meaning to an 
all-zero MAC address.

The patch also corrects the check call in test_windll_getnode since the tested 
function always generates UUID from a MAC address.

--
components: Tests
files: 0001-Allow-for-all-zero-MAC-based-node-ID-e.g.-mobile-mod.patch
keywords: patch
messages: 303360
nosy: Ivan.Pozdeev
priority: normal
severity: normal
status: open
title: test_uuid: test_getnode and test_windll_getnode fail if connected to the 
Internet via an Android phone
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: 
https://bugs.python.org/file47178/0001-Allow-for-all-zero-MAC-based-node-ID-e.g.-mobile-mod.patch

___
Python tracker 

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

[issue31641] concurrent.futures.as_completed() no longer accepts arbitrary iterables

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +3814

___
Python tracker 

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

[issue31641] concurrent.futures.as_completed() no longer accepts arbitrary iterables

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 574562c5ddb2f0429aab9af762442e6f9a3f26ab by Łukasz Langa in 
branch 'master':
bpo-31641: Allow arbitrary iterables in `concurrent.futures.as_completed()` 
(#3830)
https://github.com/python/cpython/commit/574562c5ddb2f0429aab9af762442e6f9a3f26ab


--

___
Python tracker 

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

[issue31582] Add _pth breadcrumb to sys.path documentation

[Steve Dower]

Steve Dower  added the comment:

Sounds like a good idea.

I hope that sys.path initialization is documented as well for POSIX as it is 
for Windows, as that will make this a simple "for X, click here; for Y, click 
here" patch. Otherwise, someone will need to figure out exactly what rules are 
followed so they can be documented.

(Hey Eric - when we get that Python initialization script, we can have one set 
of rules for inferring sys.path on all platforms in easy-to-read Python code :) 
)

--
nosy: +eric.snow
stage:  -> needs patch
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

[issue31641] concurrent.futures.as_completed() no longer accepts arbitrary iterables

[Łukasz Langa]

Change by Łukasz Langa :


--
keywords: +patch
pull_requests: +3813

___
Python tracker 

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

[issue31641] concurrent.futures.as_completed() no longer accepts arbitrary iterables

[Ned Deily]

Ned Deily  added the comment:

Sounds like we need to get this fixed for 3.6.3 final which is scheduled for 
Monday (3 days).  Or revert the previous fix.

--

___
Python tracker 

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

[issue31642] None value in sys.modules no longer blocks import

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue31641] concurrent.futures.as_completed() no longer accepts arbitrary iterables

[Łukasz Langa]

Change by Łukasz Langa :


--
nosy: +haypo

___
Python tracker 

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

[issue31642] None value in sys.modules no longer blocks import

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue31642] None value in sys.modules no longer blocks import

[Christian Heimes]

Change by Christian Heimes :


--
stage:  -> needs patch
type:  -> behavior

___
Python tracker 

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

[issue31642] None value in sys.modules no longer blocks import

[Christian Heimes]

Change by Christian Heimes :


--
nosy: +brett.cannon, eric.snow, ncoghlan

___
Python tracker 

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

[issue31642] None value in sys.modules no longer blocks import

[Christian Heimes]

New submission from Christian Heimes :

Since Python 3.6, the blocking of imports is broken for 'from package import 
module' imports.

$ mkdir a
$ touch a/__init__.py a/b.py

>>> import sys
>>> sys.modules['a.b'] = None
>>> from a import b
>>> b is None
True
>>> import a.b
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: import of 'a.b' halted; None in sys.modules

Tests with Python 2.7 to master:

$ python2.7 -c "from a import b; print(b)"

$ python2.7 -c "import sys; sys.modules['a.b'] = None; from a import b"
Traceback (most recent call last):
  File "", line 1, in 
ImportError: cannot import name b
$ python2.7 -c "import sys; sys.modules['a.b'] = None; from a import b"
Traceback (most recent call last):
  File "", line 1, in 
ImportError: cannot import name b
$ python3.4 -c "import sys; sys.modules['a.b'] = None; from a import b"
Traceback (most recent call last):
  File "", line 1, in 
ImportError: import of 'a.b' halted; None in sys.modules
$ python3.5 -c "import sys; sys.modules['a.b'] = None; from a import b"
Traceback (most recent call last):
  File "", line 1, in 
ImportError: import of 'a.b' halted; None in sys.modules
$ python3.6 -c "import sys; sys.modules['a.b'] = None; from a import b"
$ ./python -c "import sys; sys.modules['a.b'] = None; from a import b"

--
components: Interpreter Core
keywords: 3.6regression
messages: 303356
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: None value in sys.modules no longer blocks import
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

[issue31641] concurrent.futures.as_completed() no longer accepts arbitrary iterables

[Łukasz Langa]

New submission from Łukasz Langa :

bpo-27144 introduced a regression for `as_completed()`: it used to accept 
arbitrary iterables but now requires sequences, otherwise raising an exception 
like:


Traceback (most recent call last):
  File "sandcastle/worker/sandcastle_worker.py", line 1266, in get_work_item
  File "jupiter/jupiter_client.py", line 166, in acquireWork
  File "jupiter/jupiter_client.py", line 241, in _acquire_multiple_async
  File "jupiter/jupiter_client.py", line 336, in _wait_for_responses
  File 
"/usr/local/fbcode/gcc-5-glibc-2.23/lib/python3.6/concurrent/futures/_base.py", 
line 217, in as_completed
total_futures = len(fs)
TypeError: object of type 'map' has no len()


Since `as_completed()` is a very popular function, we need to revert the 
behavior here.

--
assignee: lukasz.langa
keywords: 3.6regression
messages: 303355
nosy: grzgrzgrz3, lukasz.langa, ned.deily, pitrou
priority: release blocker
severity: normal
stage: patch review
status: open
title: concurrent.futures.as_completed() no longer accepts arbitrary iterables
type: behavior
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

[issue31623] Allow to build MSI installer from the official tarball

[Ivan Pozdeev]

Ivan Pozdeev  added the comment:

> Assuming 3.4 is packagable using msi and hg is the only problem, I presume 
> you could use an hg-git adapter to get an hg checkout to build from.
An official source tarball, by definition, should be able to be built 
from itself, and contain tools for that. If I take sources from a Git 
repo instead, I'm not building from a tarball. If I must do some 
undocumented magic on the extracted source to build that tools don't do, 
the tools are broken. The current ticket and the attached patch fix the 
tools.

P.S. I didn't include the patch right away 'cuz I was going to make a 
PR. But GitHub doesn't work for me for some reason lately, so attached 
it here after tried and failed.

--
nosy: +__Vano

___
Python tracker 

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

Re: Beginners and experts (Batchelder blog post)

[Chris Angelico]

On Sat, Sep 30, 2017 at 5:14 AM, Bill  wrote:
> I'll write for the possible benefit of any beginners who may be reading.  I
> guess by definition, if one still has a "bug" it's because one doesn't quite
> understand what the code is doing. And I would say you should lose your
> license if you "fix something", and don't understand why it works (within
> reason of course--some mystery's of library functions should probably remain
> so forever).

My programmer's license comes from MIT and it can't be lost.

https://opensource.org/licenses/MIT

Kappa

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

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 66c2b9f13ef2197a5212fd58372173124df76467 by Serhiy Storchaka 
(Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31285: Remove splitlines identifier from Python/_warnings.c (GH-3803) 
(#3829)
https://github.com/python/cpython/commit/66c2b9f13ef2197a5212fd58372173124df76467


--

___
Python tracker 

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

Re: Redirecting stdio streams with a context manager

[Peter Otten]

Steve D'Aprano wrote:

> In the standard library's contextlib.py module, there is a class for
> redirecting standard I/O streams, and two public functions. The code is
> short enough to reproduce here:
> 
> # From Python 3.5
> 
> class _RedirectStream:
> _stream = None
> def __init__(self, new_target):
> self._new_target = new_target
> # We use a list of old targets to make this CM re-entrant
> self._old_targets = []
> def __enter__(self):
> self._old_targets.append(getattr(sys, self._stream))
> setattr(sys, self._stream, self._new_target)
> return self._new_target
> def __exit__(self, exctype, excinst, exctb):
> setattr(sys, self._stream, self._old_targets.pop())
> 
> class redirect_stdout(_RedirectStream):
> # docstring removed
> _stream = "stdout"
> 
> class redirect_stderr(_RedirectStream):
> # docstring removed
> _stream = "stderr"
> 
> 
> 
> I don't understand the comment "We use a list of old targets to make this
> CM re-entrant". Under what circumstances will there ever be more than a
> single entry in _old_targets?
> 
> If you use the context manager twice:
> 
> with redirect_stdout(f1) as instance1:
> with redirect_stdout(f2) as instance2:
> pass

That's the sane approach, but I just learned that you can reuse a single 
instance:

>>> here = io.StringIO()
>>> there = io.StringIO()
>>> h = redirect_stdout(here)
>>> t = redirect_stdout(there)
>>> with h:
... print("ham")
... with t:
... print("foo")
... with h:
... print("spam")
... with t:
... print("bar")
... 
>>> here.getvalue()
'ham\nspam\n'
>>> there.getvalue()
'foo\nbar\n'


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

Re: Line terminators in Python?

[Rob Gaddi]

On 09/29/2017 10:54 AM, Stefan Ram wrote:

   In some languages, printing »'\n'«, the Unicode code point 10,
   will have the effect of printing a line terminator, which might
   mean that the output device actually receives »\r\n«.

   The line terminator ostensibly depends on the operating
   system, but actually it depends on the output system. E.g.,
   under one operating system the console might accept another
   set of line separators than an editor. (Under Windows,
   »wordpad« accepts »\n«, while »notepad« requires »\r\n«.)

   What is the recommended way to terminate a line written with
   Python? Is it »\n« or something else? For example, in Java,
   in some cases, one should terminate the line with the value
   of »java.lang.System.lineSeparator()« which might or might
   not be equal to the value of »"\n"«.

   Does it possibly depend on the entity being written to, which
   might be

   - the Python console,
   - the IDLE console,
   - the operating system console or
   - a text file?



As everyone else has said; for general purpose (any of your cases) use 
you should always just use '\n' and it automagically works.  The only 
time I've ever needed to explicitly worry about '\r' is communicating 
over sockets or serial ports to devices.  And in those cases you need to 
stuff them with bytes rather than str anyhow, so you're already down in 
the gory bits.


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

[issue31639] http.server and SimpleHTTPServer hang after a few requests

[Matt Pr]

Matt Pr  added the comment:

It has been pointed out to me that this issue may be related to chrome making 
multiple requests in parallel.

A test with wget seems to support this.

wget -E -H -k -K -p http://domain1.com:8000/domain1.html

...does not hang, whereas requests from chrome do hang.

On some level I guess I wonder about the usefulness of simple web servers if 
they choke on very basic website requests from modern browsers.

--

___
Python tracker 

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

[issue31602] assertion failure in zipimporter.get_source() in case of a bad zlib.decompress()

[Brett Cannon]

Change by Brett Cannon :


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

___
Python tracker 

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

Re: Line terminators in Python?

[Chris Warrick]

On 29 September 2017 at 19:54, Stefan Ram  wrote:
>   In some languages, printing »'\n'«, the Unicode code point 10,
>   will have the effect of printing a line terminator, which might
>   mean that the output device actually receives »\r\n«.
>
>   The line terminator ostensibly depends on the operating
>   system, but actually it depends on the output system. E.g.,
>   under one operating system the console might accept another
>   set of line separators than an editor. (Under Windows,
>   »wordpad« accepts »\n«, while »notepad« requires »\r\n«.)
>
>   What is the recommended way to terminate a line written with
>   Python? Is it »\n« or something else? For example, in Java,
>   in some cases, one should terminate the line with the value
>   of »java.lang.System.lineSeparator()« which might or might
>   not be equal to the value of »"\n"«.
>
>   Does it possibly depend on the entity being written to, which
>   might be
>
>   - the Python console,
>   - the IDLE console,
>   - the operating system console or
>   - a text file?

It depends on the mode used to open the output file.
https://docs.python.org/3/library/functions.html#open

sys.stdout is opened in 'w' mode by default (writing, text mode). Text
mode means that non-Unix newlines (\r\n, \r) are translated to '\n'
when reading, and '\n' is translated to the system local newline when
writing. So, if you’re working in text mode (which also handles
encodings and returns Unicode strings on Python 3), you can just
assume '\n'.

If you’re curious what the local newline is, look at os.linesep:
https://docs.python.org/3/library/os.html#os.linesep

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31602] assertion failure in zipimporter.get_source() in case of a bad zlib.decompress()

[Brett Cannon]

Brett Cannon  added the comment:


New changeset 01c6a8859ef2ff5545a87cf537573bd342c848bf by Brett Cannon (Oren 
Milman) in branch 'master':
bpo-31602: Fix an assertion failure in zipimporter.get_source() in case of a 
bad zlib.decompress() (GH-3784)
https://github.com/python/cpython/commit/01c6a8859ef2ff5545a87cf537573bd342c848bf


--

___
Python tracker 

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

Re: Line terminators in Python?

[Chris Angelico]

On Sat, Sep 30, 2017 at 3:54 AM, Stefan Ram  wrote:
>   In some languages, printing »'\n'«, the Unicode code point 10,
>   will have the effect of printing a line terminator, which might
>   mean that the output device actually receives »\r\n«.
>
>   The line terminator ostensibly depends on the operating
>   system, but actually it depends on the output system. E.g.,
>   under one operating system the console might accept another
>   set of line separators than an editor. (Under Windows,
>   »wordpad« accepts »\n«, while »notepad« requires »\r\n«.)
>
>   What is the recommended way to terminate a line written with
>   Python? Is it »\n« or something else? For example, in Java,
>   in some cases, one should terminate the line with the value
>   of »java.lang.System.lineSeparator()« which might or might
>   not be equal to the value of »"\n"«.
>
>   Does it possibly depend on the entity being written to, which
>   might be
>
>   - the Python console,
>   - the IDLE console,
>   - the operating system console or
>   - a text file?
>

Always use "\n". In the event that you actually need "\r\n", transform
that on output. In effect, you can treat "Windows-style newlines" vs
"POSIX-style newlines" as a form of text encoding, to be dealt with at
boundary locations only; when you read a file, you clean up the
newlines, and when you write, you *might* transform them. Notepad
sucks, so don't do things just for its sake; but certain network
protocols stipulate carriage return/line feed as their end-of-line.
HTTP, for instance, is clearly specified as such in RFC 2616 [1] -
section 19.3 recommends that "\n" be accepted for the sake of
interoperability, but the official line ending is CR LF. So if you're
writing to a socket, you might do a two-step process of transforming
newlines and also encoding UTF-8, but inside the application, keep
everything as Unicode text with "\n" between lines.

ChrisA

[1] https://www.ietf.org/rfc/rfc2616.txt
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Line terminators in Python?

[Thomas Jollans]

On 29/09/17 19:54, Stefan Ram wrote:
>   In some languages, printing »'\n'«, the Unicode code point 10,
>   will have the effect of printing a line terminator, which might
>   mean that the output device actually receives »\r\n«.
>
>   The line terminator ostensibly depends on the operating
>   system, but actually it depends on the output system. E.g.,
>   under one operating system the console might accept another
>   set of line separators than an editor. (Under Windows,
>   »wordpad« accepts »\n«, while »notepad« requires »\r\n«.)
>
>   What is the recommended way to terminate a line written with
>   Python? Is it »\n« or something else? For example, in Java,
>   in some cases, one should terminate the line with the value
>   of »java.lang.System.lineSeparator()« which might or might
>   not be equal to the value of »"\n"«.
>
>   Does it possibly depend on the entity being written to, which
>   might be
>
>   - the Python console,
>   - the IDLE console,
>   - the operating system console or
>   - a text file?
>
Use \n.

For text I/O, Python translates \n to \r\n on Windows. For binary I/O,
it doesn't. (This means that it's important to specify text or binary
mode in your calls to open() if you want your code to be portable).

\r\n is not translated to \n on Unix. So, if you want your code to do
the right thing, use \n.

-- Thomas

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

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I just missed PR 3803.

--

___
Python tracker 

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

Re: Spacing conventions

[Chris Angelico]

On Sat, Sep 30, 2017 at 3:46 AM, Steve D'Aprano
 wrote:
> On Fri, 29 Sep 2017 03:01 pm, Chris Angelico wrote:
>
>> On Fri, Sep 29, 2017 at 2:38 PM, Steve D'Aprano
>>  wrote:
>>> On Thu, 28 Sep 2017 03:56 pm, Bill wrote:
>>>
 I worked in maintenance programming.  You got the hand you were dealt!
 And you weren't allowed to "improve" the code unless the customer
 contracted you to do so.
>>>
>>> How do you tell the difference between a bug fix and an code improvement, if
>>> the behaviour of the program remains the same?
>>
>> If the behaviour remains *exactly* the same, then it's a code
>> improvement (aka a refactoring), not a bug fix. Or, looking at it
>> another way: if there is absolutely no change to behaviour, how could
>> you tell that there was a bug in it?
>
> Well obviously you fix the bug, not just refactor and keep the bug. Sorry if
> that wasn't clear enough.
>
>
>> And yes, trying to convince a customer that it's worth paying for
>> improvements that don't change anything visible is hard.
>
> The point of refactoring is to make it easy to fix the bug:
>
> "Two hours refactoring, plus thirty seconds to fix the bug; versus 18 hours to
> fix the bug without refactoring."
>
> Plus or minus six weeks on each of those times *tongue pressed firmly in 
> cheek*
>
>
> But more seriously, I'm not suggesting you refactor the whole code base. You
> only refactor the bit you are touching *right now*.

This is the easy one. You're touching this code, you improve it. That
applies to most things - style issues, local variable names, whatever.
You don't make sweeping changes, but when you're messing with things
anyway, you can clean things up.

> Don't even mention refactoring. That sounds like an improvement, and they said
> they don't want improvements.
>
> But even the most unreasonable client will surely understand that before you 
> can
> fix the bug, you have to find it, and that requires understanding the code.
> Cleaning up the *immediately relevant section of code* (giving variables
> meaningful names, extracting common functionality, etc) is part of the
> necessary process of understanding the code and finding the cause of the bug 
> in
> the shortest possible time, and the fact that you end up with cleaner code and
> less technical debt at the end is a happy accident. That's not why you did it,
> so technically all you did was fix the bug, exactly as told.
>
> (They didn't tell you *how* to fix the bug. If they knew how, they wouldn't 
> need
> you.)

The trouble is that sometimes the refactoring doesn't pay for itself
with today's bug, but it might with tomorrow's bugs. Do you spend two
hours refactoring and bugfixing, or one hour just fixing the bug and
coping with the mess?

> But I bet that for *most*
> customers, if you give them the choice between:
>
> (1) Minimize the number of lines of code changed; or
>
> (2) Minimize the number of dollars on the invoice
>
> they'll usually prefer (2).

The improvement won't minimize the number of dollars on *this*
invoice. Can you sell them a line item of "future bug fixes will take
less time"? You can't put an actual figure on it ("will save 0.5 hours
per fortnight for the next year"), but you know the benefit is real.
That's why it's hard to sell the refactor.

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

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 8b4ff53c440dfcde40fbeb02c5e666c85190528f by Serhiy Storchaka 
(Oren Milman) in branch 'master':
bpo-31285: Remove splitlines identifier from Python/_warnings.c (#3803)
https://github.com/python/cpython/commit/8b4ff53c440dfcde40fbeb02c5e666c85190528f


--

___
Python tracker 

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

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +3812

___
Python tracker 

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

[issue28280] Always return a list from PyMapping_Keys/PyMapping_Values/PyMapping_Items

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PySequence_List() is the simplest way in C. I don't know whether we need 
special error messages now. But for compatibility keep them.

--

___
Python tracker 

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

Re: Spacing conventions

[Steve D'Aprano]

On Fri, 29 Sep 2017 03:01 pm, Chris Angelico wrote:

> On Fri, Sep 29, 2017 at 2:38 PM, Steve D'Aprano
>  wrote:
>> On Thu, 28 Sep 2017 03:56 pm, Bill wrote:
>>
>>> I worked in maintenance programming.  You got the hand you were dealt!
>>> And you weren't allowed to "improve" the code unless the customer
>>> contracted you to do so.
>>
>> How do you tell the difference between a bug fix and an code improvement, if
>> the behaviour of the program remains the same?
> 
> If the behaviour remains *exactly* the same, then it's a code
> improvement (aka a refactoring), not a bug fix. Or, looking at it
> another way: if there is absolutely no change to behaviour, how could
> you tell that there was a bug in it?

Well obviously you fix the bug, not just refactor and keep the bug. Sorry if
that wasn't clear enough.


> And yes, trying to convince a customer that it's worth paying for
> improvements that don't change anything visible is hard.

The point of refactoring is to make it easy to fix the bug:

"Two hours refactoring, plus thirty seconds to fix the bug; versus 18 hours to
fix the bug without refactoring."

Plus or minus six weeks on each of those times *tongue pressed firmly in cheek*


But more seriously, I'm not suggesting you refactor the whole code base. You
only refactor the bit you are touching *right now*. That's especially relevant
for Bill's comment about loops which are hundreds of lines long. There's a bug
somewhere in the loop, and finding the bug is going to take many hours. So
spend half that time cleaning the loop up by factoring bits of it out (if
possible!) in order to (1) understand what the loop does, and (2) simplify the
debugging process.

Technically its an improvement. But its not a *functional* improvement, which is
what people usually mean when they say no improvements, only bug fixes. It is a
code-quality improvement[1] *necessary to fix the bug*.

Perhaps not strictly necessary. You could spend five times as long fixing the
bug (and introducing two new ones) by *not* refactoring.

Of course, I understand that sometimes there are political reasons why you can't
do that, and they're not always bad reasons.  But I bet that for *most*
customers, if you give them the choice between:

(1) Minimize the number of lines of code changed; or

(2) Minimize the number of dollars on the invoice

they'll usually prefer (2).

Don't try to sell them on code refactoring as an investment for the future,
they're not interested.

Don't try to convince them that they need to reduce technical debt. Debt is
something for the next generation to worry about[2].

Don't even mention refactoring. That sounds like an improvement, and they said
they don't want improvements.

But even the most unreasonable client will surely understand that before you can
fix the bug, you have to find it, and that requires understanding the code.
Cleaning up the *immediately relevant section of code* (giving variables
meaningful names, extracting common functionality, etc) is part of the
necessary process of understanding the code and finding the cause of the bug in
the shortest possible time, and the fact that you end up with cleaner code and
less technical debt at the end is a happy accident. That's not why you did it,
so technically all you did was fix the bug, exactly as told.

(They didn't tell you *how* to fix the bug. If they knew how, they wouldn't need
you.)

But, as always, this is risky if you don't have a good test suite.



> Which is why 
> a lot of companies end up merely paying interest on their technical
> debt, and never paying off any of the capital.
> 
> ChrisA


[1] Maybe. The downside of piecemeal refactoring is that sometimes it increases
complexity until you pass a critical point and it starts decreasing it again.

[2] And that's not always a bad thing. Debt is not always bad: its money that
you can invest in building your infrastructure or startup or keeping a roof
over your head until you find a job, and it makes sense to delay paying off the
debt until you have a better income stream that will afford it more easily.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue31619] Strange error when convert hexadecimal with underscores to int

[Stefan Krah]

Stefan Krah  added the comment:

> We see if digits * bits_per_char + PyLong_SHIFT -1 overflows an int?

Yes, but the check is too late: UB can already occur in this calculation
and then all bets are off.


It looks like 'n' was Py_ssize_t in 2.7. :)

--
nosy: +skrah

___
Python tracker 

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

[issue31619] Strange error when convert hexadecimal with underscores to int

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

The error is raised when the number of underscores is at least (PyLong_SHIFT - 
1) // bits_per_char.

--

___
Python tracker 

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

[issue31619] Strange error when convert hexadecimal with underscores to int

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +3811

___
Python tracker 

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

[issue31638] zipapp module should support compression

[Paul Moore]

Change by Paul Moore :


--
assignee:  -> paul.moore
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

[issue31638] zipapp module should support compression

[Paul Moore]

Paul Moore  added the comment:


New changeset d87b105ca794addf92addb28293c92a7ef4141e1 by Paul Moore (Zhiming 
Wang) in branch 'master':
bpo-31638: Add compression support to zipapp (GH-3819)
https://github.com/python/cpython/commit/d87b105ca794addf92addb28293c92a7ef4141e1


--

___
Python tracker 

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

Re: Beginners and experts (Batchelder blog post)

[Chris Angelico]

On Sat, Sep 30, 2017 at 2:42 AM, Steve D'Aprano
 wrote:
> Oh, and I'd like to make a (moderate) defense of a kind of "bug fixing by 
> random
> perturbation". Obviously making unrelated, arbitrary changes to code is bad.
> But making non-arbitrary but not fully understood changes to relevant code
> sections can be useful in (at least) two scenarios.
>
> (1) I know there's a bug in a specific chunk of code, but I'm having trouble
> working out where. When everything else fails, if I perturb the code a bit
> (reorder lines, calculate things in a different order, rename variables, etc)
> it may change the nature of the bug enough for me to understand what's
> happening.
>
> That's not *random* or *arbitrary* changes, but they are changes not directed 
> at
> any specific outcome other than "make the code a bit different, and see if the
> error changes". I'd like to say it is the debugging technique of last resort,
> except its perhaps not quite as *last* resort as I'd like, especially in code
> I'm not familiar with.
>
> Its an experiment, but not really "carefully designed". Its more like "what
> happens if we hit this bit with a hammer?" except that programmers, unlike
> engineers, have the luxury of an Undo switch :-)

Sometimes, when I'm debugging something with one of my students, I'll
say something like "Let's do something stupid". That prefaces a
suggested change that is, perhaps:
* logging something that, by all sane logic, cannot possibly be wrong;
* altering the form of a piece of code in a way that shouldn't affect anything;
* changing something that logically should break the code worse, not fix it;
* or worse.

They're still not "random" changes, but when you exhaust all the
logical and sane things to try, sometimes you do something stupid and
it reveals the bug. I wouldn't EVER tell someone to assume that
they've hit a language or library bug - but if you make a meaningless
change and now it works, maybe that's what you've hit. It does happen.

"Why does my program crash when it talks to THIS server, but it's fine
talking to THAT server?"

... half an hour of debugging later ...

"Okay, so THIS server supports elliptic curve cryptography, but THAT
one doesn't. Great. That still doesn't explain the crash."

... two hours of debugging later ...

"Huh. Maybe this library has a bug with ECC?"

That's pretty close to what happened to me today, with the exception
that I spent less time on it (because I had the library's source code
handy). But in any case, it's a good reason to occasionally try
something stupid.

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

[issue31640] Document exit() from parse_args

[R. David Murray]

R. David Murray  added the comment:

I think this is reasonable, but do note that this is covered in 16.4.4.2, and 
the fact that help exits is actually a property of help, not parse_args.  That 
is, the docs are correct and complete as they stand, but I agree that it would 
be helpful to have the summary include this information as well.

--
nosy: +r.david.murray
versions: +Python 2.7 -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

[issue31602] assertion failure in zipimporter.get_source() in case of a bad zlib.decompress()

[Brett Cannon]

Change by Brett Cannon :


--
assignee:  -> brett.cannon
nosy: +brett.cannon

___
Python tracker 

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

Redirecting stdio streams with a context manager

[Steve D'Aprano]

In the standard library's contextlib.py module, there is a class for redirecting
standard I/O streams, and two public functions. The code is short enough to
reproduce here:

# From Python 3.5

class _RedirectStream:
_stream = None
def __init__(self, new_target):
self._new_target = new_target
# We use a list of old targets to make this CM re-entrant
self._old_targets = []
def __enter__(self):
self._old_targets.append(getattr(sys, self._stream))
setattr(sys, self._stream, self._new_target)
return self._new_target
def __exit__(self, exctype, excinst, exctb):
setattr(sys, self._stream, self._old_targets.pop())

class redirect_stdout(_RedirectStream):
# docstring removed
_stream = "stdout"

class redirect_stderr(_RedirectStream):
# docstring removed
_stream = "stderr"



I don't understand the comment "We use a list of old targets to make this CM
re-entrant". Under what circumstances will there ever be more than a single
entry in _old_targets?

If you use the context manager twice:

with redirect_stdout(f1) as instance1:
with redirect_stdout(f2) as instance2:
pass

the two calls will return different instances and sys.stdout will be set as
follows:

# before first call to redirect_stdout
sys.stdout = __stdout__  # the original setting

# first call __enter__
save __stdout__ in instance1._old_targets
set sys.stdout = f1

# second call __enter__
save f1 in instance2._old_targets
set sys.stdout = f2

# second call __exit__
restore sys.stdout = f1

# first call __exit__
restore sys.stdout = __stdout__


I'm not seeing why _old_targets is a list.


Can anyone explain?


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue31638] zipapp module should support compression

[Paul Moore]

Paul Moore  added the comment:

Definitely. The reason it uses uncompressed files is simply an oversight on my 
part - I hadn't realised the default for zipfile was uncompressed.

--

___
Python tracker 

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

[issue28280] Always return a list from PyMapping_Keys/PyMapping_Values/PyMapping_Items

[Oren Milman]

Oren Milman  added the comment:

I would be happy to write a PR that implements that.

However, i am not sure which way is better to construct a list from the return
value (an iterable, hopefully) of keys() etc.:
- Call PyList_Type() (in each of PyMapping_Keys() etc.) on the iterable, and
  overwrite the error message in case it is a TypeError.
- Write a helper function iterable_as_list(), which uses PyObject_GetIter() and
  PySequence_List(), and call it in each of PyMapping_Keys() etc..
  (iterable_as_list() would receive "keys" etc., so that it would raise the
  appropriate error message, in case of a TypeError.)

ISTM that the first one is simpler, but I am not sure about the performance
difference between them.

--
nosy: +Oren Milman

___
Python tracker 

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

[issue31640] Document exit() from parse_args

[Charles Merriam]

New submission from Charles Merriam :

It is unexpected to testers and users to ArgParse that it terminates the 
process; one usually expects an error code.  Fix by modifying documentation to 
section 16.4.4 The parse_args() Method. 

Change the words "Return the populated namespace." to "Return the populated 
namespace, or exit with a status 0 if the help message is printed, or exit with 
status 2 if an invalid argument was parsed."

--
assignee: docs@python
components: Documentation
messages: 303341
nosy: CharlesMerriam, docs@python
priority: normal
severity: normal
status: open
title: Document exit() from parse_args
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is easy to write a workaround for the first case (but it is not ). The 
workaround for the second case would be too complex. I prefer to skip the test. 
Unfortunately the version of ncurses is not exposed on Python level, thus the 
skipping is OS-specific.

--

___
Python tracker 

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

Re: Refactoring

[Bill]

Stefan Ram wrote:


   The customer pays for the solution. The software
   manufacturer does the refactoring for it's own sake,
   because when it's a longer running project, the
   refactorings will pay for themself.



The customer owns the source code (at least where I was).  YMMV
--
https://mail.python.org/mailman/listinfo/python-list

[issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue31619] Strange error when convert hexadecimal with underscores to int

[Nitish]

Nitish  added the comment:

>> PR 3816 fixes the symptom, but not the core issue -- an overflow check 
>> depending on undefined behaviour.

> I don't understand this check completely actually. When exactly is an int too 
> large to convert?

We see if digits * bits_per_char + PyLong_SHIFT -1 overflows an int?

--

___
Python tracker 

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

Re: Beginners and experts (Batchelder blog post)

[Steve D'Aprano]

On Fri, 29 Sep 2017 08:34 pm, D'Arcy Cain wrote:

> On 09/29/2017 03:15 AM, Steve D'Aprano wrote:
>> "Carefully-designed experiments" -- yeah, that is so totally how the coders
>> I've worked with operate *wink*
>> 
>> I think that's an awfully optimistic description of how the average
>> programmer works :-)
> 
> Better not hire average programmers then.

Okay.

Can I consider the top 10% of programmers, or must I only consider only those in
the top 1%?

If I'm on a budget and the code isn't that critical, can I consider those in the
top 20% for junior roles?


> I do "Carefully-designed 
> experiments" to find non-obvious bugs so I guess I am not average.

Okay.

By the way, *in context* (before you deleted the original text) there was no
mention about "non-obvious bugs". Greg Ewing and Chris Angelico were talking
about the general difference between the process used by novices and that used
by experts and how beginners often attempt to fix bugs by making random
changes, while experts don't.

I've certainly seen beginners make arbitrary changes to unrelated parts of their
code trying to fix a bug. Often many different changes all at once. So that's
another difference between beginners and experts:

- experts have the self-control to make only one change at a time, 
  when it matters; beginners don't know when it matters.


Oh, and I'd like to make a (moderate) defense of a kind of "bug fixing by random
perturbation". Obviously making unrelated, arbitrary changes to code is bad.
But making non-arbitrary but not fully understood changes to relevant code
sections can be useful in (at least) two scenarios.

(1) I know there's a bug in a specific chunk of code, but I'm having trouble
working out where. When everything else fails, if I perturb the code a bit
(reorder lines, calculate things in a different order, rename variables, etc)
it may change the nature of the bug enough for me to understand what's
happening.

That's not *random* or *arbitrary* changes, but they are changes not directed at
any specific outcome other than "make the code a bit different, and see if the
error changes". I'd like to say it is the debugging technique of last resort,
except its perhaps not quite as *last* resort as I'd like, especially in code
I'm not familiar with.

Its an experiment, but not really "carefully designed". Its more like "what
happens if we hit this bit with a hammer?" except that programmers, unlike
engineers, have the luxury of an Undo switch :-)


(2) I hate off by one errors, and similar finicky errors that mean your code is
*almost* right. I especially hate them when I'm not sure which direction I'm
off by one. If you have unit tests that are failing, sometimes its quicker and
easier to randomly perturb the specific piece of code until you get the right
answer, rather than trying to analyse it.

"Should I add one here? Maybe subtract one? Start at zero or one? Ah bugger it,
I'll try them all and see which one works."

This is only effective when you have exhaustive tests that exercise all the
relevant cases and can tell you when you've hit the right solution.

On the other hand, sometimes the bug isn't as clear cut as you thought, and you
really do need to analyse the situation carefully.


> I get the impression that many people here are above average too.
> 
> Personally I think you are being pessimistic about "average"
> programmers.  Perhaps you just know the sloppy kind.

One needs to only look at the quality of software, whether open source or
commercial closed source, to feel pessimistic about the ability of even
excellent programmers to write good, secure, bug-free code.

The complexity of code increases faster than our ability to manage that
complexity.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Textwrap doesn't honour NO-BREAK SPACE

[Steve D'Aprano]

On Fri, 29 Sep 2017 07:11 pm, Wolfgang Maier wrote:

> On 29.09.2017 11:05, Wolfgang Maier wrote:
>> On 29.09.2017 07:25, Steve D'Aprano wrote:
>>> I'm pretty sure this is a bug.
>>>
>> 
>> Yes, it is a bug, but a known one: https://bugs.python.org/issue20491
>> 
>> The fix got backported even to 3.5, but I guess it depends which minor
>> version you are running. I'm pretty sure that explains why people report
>> different outcomes.
>> 
>> Best,
>> Wolfgang
>> 
> 
> To be specific, this should be fixed from 3.5.3 and 3.6.0b3 onwards.

Thanks everyone who answered.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue31634] Consider installing wheel in ensurepip by default

[Ned Deily]

Change by Ned Deily :


--
nosy: +ned.deily

___
Python tracker 

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

[issue31625] stop using ranlib

[STINNER Victor]

STINNER Victor  added the comment:

Thanks ;-)

--

___
Python tracker 

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

[issue31619] Strange error when convert hexadecimal with underscores to int

[Nitish]

Nitish  added the comment:

> PR 3816 fixes the symptom, but not the core issue -- an overflow check 
> depending on undefined behaviour.

I don't understand this check completely actually. When exactly is an int too 
large to convert?

--

___
Python tracker 

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

[issue31625] stop using ranlib

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset 6fb0e4a6d085ffa4e4a6daaea042a1cc517fa8bc by Benjamin Peterson in 
branch 'master':
explicitly list objects for the ar command (#3824)
https://github.com/python/cpython/commit/6fb0e4a6d085ffa4e4a6daaea042a1cc517fa8bc


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

[issue31638] zipapp module should support compression

[Éric Araujo]

Change by Éric Araujo :


--
keywords: +needs review
nosy: +paul.moore
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

[issue31625] stop using ranlib

[Benjamin Peterson]

Change by Benjamin Peterson :


--
pull_requests: +3809
stage: resolved -> patch review

___
Python tracker 

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

[issue31634] Consider installing wheel in ensurepip by default

[Éric Araujo]

Change by Éric Araujo :


--
nosy: +dstufft, merwok, ncoghlan
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.8

___
Python tracker 

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