New submission from Erik Bray :
Not that there is any great reason to write a zip file to /dev/null, but I had
some code that happened to do so which worked on Python 2.7, but at some point
this broke:
Python 3.8.0a0 (heads/master:fc7d1b3, Oct 5 2018, 09:49:57)
[GCC 4.8.4] on linux
Type
Erik Bray added the comment:
The regression was introduced by issue26039.
It does seem to be Linux-specific with seek/tell on /dev/null. For example, I
cannot reproduce the issue on Cygwin.
--
___
Python tracker
<https://bugs.python.
Erik Bray added the comment:
On Cygwin the same tests give
>>> f = open('/dev/null', 'wb')
>>> f.seekable()
True
>>> f.write(b'abcdefgh')
8
>>> f.tell()
8
>>> f.seek(8)
8
>>> f.
Erik Bray added the comment:
For the sake of completeness, same deal in pure C:
$ cat devnul.c
#include
int main(void) {
FILE *f = fopen("/dev/null", "w");
printf("tell() = %ld\n", ftell(f));
printf("write(\"abcdefgh\") = %zu\n&quo
New submission from Erik Bray:
I've come across a few difficulties of late with the io module's handling of
files opened in append mode (any variation on 'a', 'ab', 'a+', 'ab+', etc.
The biggest problem is that the io module does not in a
Erik Bray added the comment:
Ah right, sorry about that. I just came over from the Trac site for one of my
projects where the version field is used for affected versions :)
--
___
Python tracker
<http://bugs.python.org/issue18
Erik Bray added the comment:
>> Whereas the behavior of O_APPEND causes an automatic seek to the end
>> before any write().
> True, but IIRC some systems seek on open() and some systems seek just before
> write().
I figured that workaround that seeks to the end on open
Erik Bray added the comment:
Here's an initial stab at a simple patch that just addresses the issue of
'append' not being in the mode string. Amazingly this did not break a single
existing test, though I added a new one to test how FileIO objects display
their mode str
Changes by Erik Bray :
Added file: http://bugs.python.org/file31588/issue_18876_patch_2.diff
___
Python tracker
<http://bugs.python.org/issue18876>
___
___
Python-bug
Erik Bray added the comment:
Thank you! Has there been a separate issue opened for the BufferedWriter bug
or can that be covered by this issue as well?
--
___
Python tracker
<http://bugs.python.org/issue18
New submission from Erik Bray:
This is probably a pretty rare corner case, but a coworker reported this to me
while testing code that does open several ftp connections to different files.
--
components: Library (Lib)
files: urllib-request-ftpcache-error.patch
keywords: patch
messages
Erik Bray added the comment:
Ah, didn't know that about "crash".
I wanted to add a test but hesitated only because that code is not well tested
to begin with (perhaps, hence, this going unnoticed for so long). But I guess
it could be done by mocking the f
Erik Bray added the comment:
Thanks Skyler for finishing the job. I got busy/distracted.
--
___
Python tracker
<http://bugs.python.org/issue21463>
___
___
Pytho
New submission from Erik Bray:
In #18876 I pointed out the following issue:
BufferedWriter/Random doesn't know the raw file was opened with O_APPEND so the
writes it shows in the buffer differ from what will actually end up in the
file. For example:
>>> f = open('test&
Erik Bray added the comment:
To me, Masayuki's patch is an acceptable work-around for the time being. I
don't *like* it because the fact remains that native TLS can work on these
platforms and falling back on Python's slower implementation isn't necessary.
That said
Erik Bray added the comment:
I'm still pretty happy with the previous patch, personally, since I don't need
the tracemalloc module. But it seems like that should be fixed (or if nothing
else that code in _tracemalloc.c should check Py_HAVE_NATIVE_TLS too).
I like the idea
New submission from Erik Bray:
This patch works around a couple different problems with running the
test_asyncore tests in Cygwin, both of which are due to bugs in Cygwin itself
and not in Python. As such, I don't think Python should try to work around
these issues in general, but I do
Erik Bray added the comment:
Thanks Masayuki for the updated patch, and especially for the additional test
cases.
Looking at the patch, it occurs to me that this solution seems to be the
minimal needed to fix the issue that we were originally trying to fix, without
adding too much additional
Erik Bray added the comment:
Decorater, since this issue was already closed, could you open a new one? And
when you do, please add me to the nosy list.
I'm still planning to get a Cygwin built bot up for Python, I've just had other
various
New submission from Erik Bray:
When building Python on Cygwin, both a libpython-X.Y.dll and a
libpython-X.Y.dll.a are created (see https://cygwin.com/cygwin-ug-net/dll.html).
The latter is an "import library"
consisting of stubs for functions in the DLL so that it can be linked
to
Erik Bray added the comment:
I've run into this recently. Is there anything I can do to shepherd this issue
toward a resolution status?
--
nosy: +erik.bray
___
Python tracker
<http://bugs.python.org/is
Erik Bray added the comment:
I can confirm that the last attached patch on this issue fixes this particular
issue with building on Cygwin. There are other issues but this is definitely
one of them.
--
nosy: +erik.bray
___
Python tracker
<h
Erik Bray added the comment:
I agree--this has the same problem on Cygwin, where pthread_key_t is not just a
typedef'd integer (in fact it's a pointer to an instance of a class).
Anyways as Ed wrote above POSIX says this is supposed to be an opaque type and
there's no reason to
Erik Bray added the comment:
I'm not really sure what "long" has to do with it...
The problem is that the PyThread API uses ints to represent TLS keys, and has
for about as long as it's existed (maybe what you meant by "long"). But when
support for native TL
Erik Bray added the comment:
(Of course, maintaining such a list might take some care, but only when
creating and deleting keys--it wouldn't add any overhead to using them to
get/set values.)
--
___
Python tracker
<http://bugs.py
Erik Bray added the comment:
The good news about this (in the pthread case) is that it does not need to be
seen as some workaround for unusual platforms, but rather making the existing
code more POSIX-compliant (and hence correct).
The Win32 side I'm a little less worried about becaus
Erik Bray added the comment:
FWIW I've created an initial patch for this. Seems to work fine, but it's a
bit of a mess and I have a few small implementation concerns. I'll try to get
it cleaned up sometime in the next few days a
Changes by Erik Bray :
--
assignee: -> erik.bray
___
Python tracker
<http://bugs.python.org/issue21085>
___
___
Python-bugs-list mailing list
Unsubscrib
Erik Bray added the comment:
Thanks Masayuki for the updated patch. I agree, the new approach looks better.
I will review the patch more carefully and test it soon.
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issu
Changes by Erik Bray :
Added file:
https://bugs.python.org/file44263/3.4-issue21085-struct_siginfo-2.patch
___
Python tracker
<https://bugs.python.org/issue21
Changes by Erik Bray :
Added file:
https://bugs.python.org/file44262/tip-issue21085-struct_siginfo-2.patch
___
Python tracker
<https://bugs.python.org/issue21
Changes by Erik Bray :
Added file:
https://bugs.python.org/file44264/3.3-issue21085-struct_siginfo-2.patch
___
Python tracker
<https://bugs.python.org/issue21
Erik Bray added the comment:
I've reviewed masamoto's last patch 3.5-issue21085-struct_siginfo-2.patch
It applies cleanly and allows the signals module to compile on Cygwin64 2.5.1 /
Windows 10. I attached versions of the patch that apply cleanly to tip, 3.4,
and 3.3 as well.
How
Erik Bray added the comment:
Here's a first stab at a patch for this. A linked list is maintained which
maps pthread_key_t instances to an int "key_id" that is used for the PyThread
API. Each function needs to map a given key_id to the actual pthread_key_t.
This adds
Changes by Erik Bray :
--
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue25658>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Erik Bray :
--
keywords: +patch
Added file: https://bugs.python.org/file44269/issue25658-1.patch
___
Python tracker
<https://bugs.python.org/issue25
Erik Bray added the comment:
I have confirmed Masayuki's patch (3.4-distutils-shlibext.patch) fixes a few
build issues on Cygwin.
At its core, what it's fixing is allowing UnixCCompiler.find_library_file to
find import libraries on Cygwin.
That in turn is necessary for --with-sys
New submission from Erik Bray:
This is vaguely related to issue14067, though the patch suggested there would
make this problem worse, not better.
This addresses a problem that cropped up on OSX in which some code that, for
Good Reasons, generates a module in a package directory and then
Changes by Erik Bray :
--
keywords: +patch
Added file: http://bugs.python.org/file29286/94e671589c0e.diff
___
Python tracker
<http://bugs.python.org/issue17
Erik Bray added the comment:
Why should modifying the file in place be expected to do anything with respect
to the directory cache? If that module has already been imported then
modifying it should not require the cache to be invalidated.
If the file is modified *before* it's imported t
Erik Bray added the comment:
Put another way, the cache associated with a FileFinder only keeps track of the
filenames in a directory, and not their individual mtimes. So if a new file is
added to the directory the cache should be invalided. Likewise if a file is
removed.
If a file is
Erik Bray added the comment:
Fair enough, but then I would propose removing the automatic cache invalidation
based on mtime altogether. It's just not reliable enough--this caused
previously working code to break unexpectedly, and only on a single platform at
that.
I'm
Erik Bray added the comment:
I should add, Antoine's counter-example of a file that's renamed or replaced
already doesn't work either under OSX. So while this solution won't address
that (even more narrow) use case, it would at least improve the existing
situation for
Erik Bray added the comment:
Dropping the implicit invalidation altogether works for me. I was hoping to
find a better solution because for the majority of use cases I personally care
about the existing behavior is preferable.
That said I have to support OSX users as possibly the majority of
Changes by Erik Bray :
--
nosy: +erik.bray
___
Python tracker
<http://bugs.python.org/issue23400>
___
___
Python-bugs-list mailing list
Unsubscribe:
Erik Bray added the comment:
For what it's worth (since it was mentioned toward the end of this thread as an
offending package) Astropy has a patch now to fix its misbehavior with respect
to this issue.
I do feel like this would be nice to fix though, since I think it's awkward to
Changes by Erik Bray :
--
nosy: +erik.bray
___
Python tracker
<http://bugs.python.org/issue24651>
___
___
Python-bugs-list mailing list
Unsubscribe:
Erik Bray added the comment:
As I wrote (late) in the thread that shall not be named, I don't think it makes
any sense to have magic assert_ methods on the Mock object. Not only does the
"magic" clearly lead to too many ambiguities and other problems--I think they
make less se
Erik Bray added the comment:
Would it be possible to add the functions and *not* deprecate assert_ methods?
The existing solution is still acknowledged to be an incomplete solution. It
is still possible to make other typos that result in unintentional
non-assertions (it's also not ent
New submission from Erik Bray:
This issue is directly related to http://bugs.python.org/issue5890, the
solution to which I think was incomplete.
The examples below use a trivial subclass of property (but apply as well to a
less trivial one):
>>> class myproperty(property): pass
Erik Bray added the comment:
Sorry for the hold up. Attached is another diff providing a test. I think
this is all that's really needed (since this is just a special case of the
issue already tested for in this particular test class.
--
Added file: http://bugs.python.org/file
Erik Bray added the comment:
A read-only classproperty is fairly trivial to implement in pure Python and has
been done.
A good reason to have a classproperty implementation in CPython would be to
support settable/deleteable classproperties. The problem is that can't be done
wit
New submission from Erik Bray:
Although admittedly rare, I've on more than one occasion wanted to inspect the
tp_flags of a given class. It seems silly to me that although tp_flags is
exposed to Python via type.__flags__, I then have to go rummaging around in
Include/object.h in ord
Erik Bray added the comment:
Alternatively (or additionally) it would be nice if type.__flags__ were some
PyStructSequence-based type (though as a subtype of int for backwards compat).
--
___
Python tracker
<http://bugs.python.org/issue24
Erik Bray added the comment:
Interesting--in fairness to myself, that test seems to fail without my patch
too (without the -R it passes, but with -R3:3 it fails). So it looks like a
pre-existing issue. But I'll see if I can do something about that while I
Erik Bray added the comment:
Actually, of course that test would fail when run repeatedly--it sets the
property docstring from 'Eggs' to 'Spam' on the first run, but then doesn't set
it back to its original value. Since the PropertyWritableDocs class used in
tha
Erik Bray added the comment:
Attached an additional patch to test_property_decorator_doc_writable so that it
can pass on repeated runs.
--
Added file: http://bugs.python.org/file40504/property-doc-test2.patch
___
Python tracker
<h
Erik Bray added the comment:
This would definitely be nice to fix. I panicked a bit because of this when I
compiled my extension modules against Python 3.5 for the first time.
--
nosy: +erik.bray
___
Python tracker
<http://bugs.python.
Erik Bray added the comment:
I just recently discovered this myself. In the process of debugging the issue
I also noticed the same bug that is now fixed via Issue 24402.
While I agree that Issue 24402 mostly mitigates the issue I think this patch is
still worthwhile, as the current behavior
Erik Bray added the comment:
> I think the above code *should* break
Actually, I see now that Serhiy's patch would allow this example to just pass
through to the non-interactive fallback. So I take it back that my example
should break--I think using the fallback would also
Changes by Erik Bray :
--
nosy: +erik.bray
___
Python tracker
<http://bugs.python.org/issue8027>
___
___
Python-bugs-list mailing list
Unsubscribe:
Erik Bray added the comment:
I'm also inclined to agree that the buggy code (and it *is* buggy even if it
was meant to fix something originally) should be removed outright. Nobody can
point to a real world issue that it fixes anymore, yet we can point to real
world consequences caus
Erik Bray added the comment:
Thanks for the updated patch. LGTM.
--
___
Python tracker
<http://bugs.python.org/issue24766>
___
___
Python-bugs-list mailin
Erik Bray added the comment:
Hi,
First of all, I should be clear this is not just about CloudABI. In fact I
don't even know what CloudABI is. I'm personally working toward getting a
working/stable buildbot for Cygwin, so that I can move Python toward supporting
it again. Cygw
Erik Bray added the comment:
Ah, I wasn't thinking clearly toward the bottom of my last message. I see now
that after a fork, _PyGILState_Reinit calls PyThread_delete_key followed by a
new PyThread_create_key--in the current version of my patch that would result
in putting the autoTLSk
Changes by Erik Bray :
--
nosy: +erik.bray
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue25750>
___
___
Python-bugs-list mai
Erik Bray added the comment:
Masayuki--concerning your above comments, I think this is similar to, if not
the same as #13756
--
___
Python tracker
<http://bugs.python.org/issue27
Erik Bray added the comment:
Thanks for the merge--targeting 3.7 for now and thinking about backporting
later sounds fine to me.
I'm also in the process of getting a Cygwin buildbot for Python up and running,
but it's been slow going. That said, having a Cygwin buildbot is
Erik Bray added the comment:
FWIW, even with this patch and --without-threads Python does *not* build
successfully on Cygwin64 (which is all I'm really interested in personally),
though it does succeed on 32-bit Cygwin. This has two related reasons:
1) The build of Python's bund
Erik Bray added the comment:
I think it would still be worth including this patch in Python. It wouldn't be
the only condition in py_curses.h for platform-specific oddities with ncurses.
This patch is still needed for the _curses module to build on Cygwin.
--
nosy: +erik
Erik Bray added the comment:
I see what you're saying--thanks for pointing out those other tickets. I'll
give #28190 a try first.
--
___
Python tracker
<http://bugs.python.o
Erik Bray added the comment:
Okay, that would explain it then. I was building from an older branch
(pre-3.7) that still has the bundled libffi.
FWIW with the fix from #2445, --with-system-ffi works (as does some trivial use
of _ctypes though I haven't run all the tests). So if the bu
New submission from Erik Bray:
This actually came up previously in #1543469 in the context of test_subprocess,
but it's a more general issue that I thought was worth addressing somehow.
The issue here is that as Cygwin tries to provide a "UNIX-like" experience, any
system inter
Erik Bray added the comment:
I agree this has a slight change in behavior which I was at first hesitant
about. But I think the previous behavior was wrong insofar as it was overly
ambiguous. I agree it should apply on MSYS2 as well (I actually thought
__CYGWIN__ was defined on MSYS2 but I
Erik Bray added the comment:
FWIW this patch broke the _pyio module on Cygwin, as the msvcrt module is not
built on Cygwin. AFAICT this is only a problem for Python built with MSVCRT,
which Cygwin does not use. When test case works as expected on Cygwin without
this.
--
nosy
New submission from Erik Bray:
Since the patch to #24881 was merged the _pyio module has been non-importable
on Cygwin, due to an attempt to import from the msvcrt module.
However, the msvcrt module is not built on Cygwin (Cygwin does not use MSVCRT).
Cygwin's libc does, however,
Erik Bray added the comment:
Hi Masayuki, thanks for the response (I thought I replied to this earlier but
maybe I only imagined it--I've been on vacation).
I agree with just about everything you write here.
I'm aware of the FreeBSD setmode(), but I figured os.setmode() could do
Erik Bray added the comment:
Thanks! Setting EXE_SUFFIX from the Makefile is much better.
--
___
Python tracker
<http://bugs.python.org/issue28441>
___
___
Pytho
Changes by Erik Bray :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue28441>
___
___
Python-bugs-list mailing list
Unsubscrib
101 - 179 of 179 matches
Mail list logo
