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 bundled libffi
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 also high
Erik Bray added the comment:
Masayuki--concerning your above comments, I think this is similar to, if not
the same as #13756
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Erik Bray <erik.m.b...@gmail.com>:
--
nosy: +erik.bray
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
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 autoTLSkey
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. Cygwin has
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-system-ffi
Changes by Erik Bray <erik.m.b...@gmail.com>:
--
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue25658>
___
_
Changes by Erik Bray <erik.m.b...@gmail.com>:
--
keywords: +patch
Added file: https://bugs.python.org/file44269/issue25658-1.patch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
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 a
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.
However, even
Changes by Erik Bray <erik.m.b...@gmail.com>:
Added file:
https://bugs.python.org/file44264/3.3-issue21085-struct_siginfo-2.patch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Changes by Erik Bray <erik.m.b...@gmail.com>:
Added file:
https://bugs.python.org/file44262/tip-issue21085-struct_siginfo-2.patch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Changes by Erik Bray <erik.m.b...@gmail.com>:
Added file:
https://bugs.python.org/file44263/3.4-issue21085-struct_siginfo-2.patch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
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 <rep...@bugs.python.org&
Changes by Erik Bray <erik.m.b...@gmail.com>:
--
assignee: -> erik.bray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21085>
___
_
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 and I'll post
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 because
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 <rep...@bugs.python.org>
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 TLS was adde
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 assume it's
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 <
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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:
Thanks for the updated patch. LGTM.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24766>
___
___
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 caused
Changes by Erik Bray <erik.m.b...@gmail.com>:
--
nosy: +erik.bray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue8027>
___
__
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 be f
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
that test is module-level
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 <
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 <rep...@bugs.python.org>
Peter Bray added the comment:
While I have not tested the patch provided, the following ls(1) command on Sun
Solaris 10 Update 8 and Oracle Solaris 10 Update 11, show that on (at least)
X86 systems, there is no -lcrypt for 64-bit builds. So a patch is required on
64-bit builds, and possibly
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 order
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 rep...@bugs.python.org
http
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
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/file40181
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
...
When using
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 entirely
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 sense from an API
Changes by Erik Bray erik.m.b...@gmail.com:
--
nosy: +erik.bray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24651
___
___
Python-bugs-list
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
have code
Changes by Erik Bray erik.m.b...@gmail.com:
--
nosy: +erik.bray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23400
___
___
Python-bugs-list
Peter Bray added the comment:
Terry,
I no longer have easy access to SPARC64 systems (they are in boxes), so
unfortunately I will not be able to contribute to this issue in the near
future.
Peter
--
components: -Tests
___
Python tracker rep
standard for binary distributions of Python projects.
You can contact me at emb...@stsci.edu with any questions or comments. Thank
you to everyone who submitted bug reports and fixes.
Erik Bray
[1] http://wheel.readthedocs.org/en/latest/
--
https://mail.python.org/mailman/listinfo/python-announce
Erik Bray added the comment:
Thanks Skyler for finishing the job. I got busy/distracted.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21463
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 ftpwrapper class
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', 'wb')
f.write
New submission from Jason Bray:
Hello, I am working in an IT group, attempting to automate our management of
python. This issue applies to both Python 3.4 and Python 2.7.5 and Python 2.7.4
On a Windows machine (both 7 and 8.1 have been tested) when python msi's are
installed from the command
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 rep...@bugs.python.org
http://bugs.python.org/issue18876
Changes by Erik Bray erik.m.b...@gmail.com:
Added file: http://bugs.python.org/file31588/issue_18876_patch_2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18876
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 any way keep track of
whether a file was opened
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 rep...@bugs.python.org
http://bugs.python.org
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 was an attempt to
normalize
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 string after being
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
Changes by Erik Bray erik.m.b...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file29286/94e671589c0e.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17330
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 that's
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
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 fine
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 what I would like
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
Erik Bray erik.m.b...@gmail.com added the comment:
+1 for the wildcard syntax.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14549
Erik Bray erik.m.b...@gmail.com added the comment:
Potential downside:
Say I have foo, foo.bar, and foo.tests. I want to install foo and foo.bar, but
not foo.tests. Then I have to manually list all the packages I do want:
packages =
foo
foo.bar
That's fine, but one nice thing about
Erik Bray erik.m.b...@gmail.com added the comment:
This patch works for me, and I'm happy with the syntax. Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11805
Erik Bray erik.m.b...@gmail.com added the comment:
FWIW, I'm for the first option for specifying package_data:
[files]
package_data =
spam = first second third
I'm pretty sure this is how I ended up implementing it in d2to1, since I needed
this functionality.
Theoretically spaces could
Erik Bray erik.m.b...@gmail.com added the comment:
When run from an uninstalled checkout, for example when developing, the
file will be found in the checkout. When run after being installed on
a Debian system, the file will be found in /usr/local/share
/spam/templates/log.txt. Each
New submission from Erik Bray erik.m.b...@gmail.com:
I just saw issue11637 [Add cwd to sys.path for hooks] and was reminded that
this would also be useful (and in fact necessary if hook code is in a package
that's under some root other than cwd).
On a related matter, the current use
New submission from Erik Bray erik.m.b...@gmail.com:
This issue was first mentioned in issue12375. The Distribution.package_dir
attribute (which also appears in a few commands) is not used in a consistent
manner. Some code expects it to be a string, while other code expects it to be
a dict
Erik Bray erik.m.b...@gmail.com added the comment:
Added issue12377 for packages_root/package_dir cleanup.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12375
Erik Bray erik.m.b...@gmail.com added the comment:
Good to know! The majority of my development is still on 2.x so it's easy to
forget things like that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12240
Erik Bray erik.m.b...@gmail.com added the comment:
Thanks Eric for your review. Obviously the last patch was rushed, and I didn't
even run the tests. It also got my changes for issue12240 mixed into it. So
I've gone ahead and attached an updated patch which incorporates your review
Erik Bray erik.m.b...@gmail.com added the comment:
Here's an update with tests. It should be applied after my patch for
issue11595.
--
Added file: http://bugs.python.org/file22299/python_issue12240-2.patch
___
Python tracker rep...@bugs.python.org
ChiPy
=
When: 7 PM Thursday June 9, 2011
Where: Google
Join us for the best meeting ever!
You will need to RSVP at http://chipy.org/
RSVP Quick Links:
YES http://chipy.org/meetings/rsvp/33/yes
MAYBE http://chipy.org/meetings/rsvp/33/maybe
Topics
--
1. 7:00
Erik Bray erik.m.b...@gmail.com added the comment:
Done. Also added support for multi-valued description-file values.
--
Added file: http://bugs.python.org/file22276/issue11595-2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Erik Bray erik.m.b...@gmail.com added the comment:
Adds support for multiple setup_hooks and updates the docs.
For now I left the option name as setup_hook, though it might make sense to
rename it to setup_hooks for consistency's sake.
--
keywords: +patch
Added file: http
Erik Bray erik.m.b...@gmail.com added the comment:
Great! I'll add a patch shortly.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12240
New submission from Erik Bray erik.m.b...@gmail.com:
I have a use case where I have a small library of setup_hook functions for
various purposes that are used by multiple projects. Some projects may want to
use more than one of these setup_hooks.
I can certainly create a wrapper hook
Erik Bray erik.m.b...@gmail.com added the comment:
As far as I've been able to tell there is no proposed syntax in the docs
specifically for package_data. The docs for the resources option seems to
suggest separating globs with spaces, which would be fine by me (wouldn't allow
paths
New submission from Erik Bray erik.m.b...@gmail.com:
In distutils the package_data option can be supplied a list of glob patterns
for each package. distutils2 currently only supports one glob per package.
This could easily be fixed by simply allowing more than one `package_name =
pattern
Erik Bray erik.m.b...@gmail.com added the comment:
I've got an additional patch to this function that also adds support for the
package_data option, for extension modules (at least as they are currently
specified in setup.cfg), and adds support for running setup_hook.
The only problem
New submission from Erik Bray erik.m.b...@gmail.com:
Attached is a patch that fixes a few miscellaneous bugs in cfg_to_args() that
were holding me up. Namely:
* A bad variable name (file - path)
* A few more fields needed to be in MULTI_FIELDS
* Added support for packages_root - package_dir
Chicago Python User Group
=
Save the date for the ``awesomest`` Chicago Python user group meeting
ever!
This Thursday we will hear from the creator of Prudence on Advanced
Caching techniques. http://threecrickets.com/prudence/ Prudence is an
open source Scalable
ChiPy
=
7 PM Thursday Aug 12, 2010 (This Thursday in the loop)
RSVP here -
https://spreadsheets.google.com/viewform?formkey=dHVLOTNTU3oxTzJKYjB3RmV4eVZkMEE6MA
Get ready for the best ChiPy meeting ever! We will head over to ITA in
the loop for this free and informative (not to mention
Peter Bray pdb...@yahoo.com.au added the comment:
Sorry for the internet lifetime I've been away.
I have tested the patch provided against the released 3.1 distribution
and all tests pass without coredumping or failing on Solaris 10 Update 6
with gcc 4.1.2. The 3.1 distribution with the patch
New submission from Peter Bray pdb...@yahoo.com.au:
Greetings,
I have downloaded and compiled Python 3.1b1 on Solaris 10 Update 6
with GCC 4.1.2 on {SPARC,x86} x {32-bit,64-bit} and encountered only one
test harness failure, which was on SPARC 64-bit.
Included below are the initial details
Chicago Python User Group
=
Come join us for our best meeting ever!
When
Thursday, May 8th, ~7pm
Topics
--
* The Screen craping console, Cycloctopus (Feighong Hsu)
* Demonstration on using the built-in Unit Testing Django Apps (Brian
Ray)
* How to get
Chicago Python User Group
=
Come join us for our best meeting ever!
When
Tuesday, April 15th, ~7pm **NOTE: TUESDAY MEETING** NO Meeting on
Thursday
Topics
--
* Web2py (Massimo Di Pierro)
* Google AppEngine Introduction / Open Discussion (Ian Bicking)
*
Thurs. December 14 2006. 7 pm.
Come join us for our December meeting. This might be our best one yet!
Mark Ramm http://compoundthinking.com/ TurboGears expert will
present. Here is Mark's blog entry: http://tinyurl.com/w33zw.
We will then open the floor for discussion on Chicago's 2008 Bid to
NOTE: This is a special meeting on next Tuesday in addition to our
normal Thursday meeting. Attend both, if you can.
Tuesday. November 14 2006. 5:30 pm.
Topics
--
Ed Leaf on Dabo is an open-source framework for developing desktop
(i.e., rich client) applications in Python.
Details
Thursday November 9 2006. 7:00 pm.
This may be our best meeting yet. This is our regular Thurs. meeting. In
addition stay tuned for a special meeting to welcome Ed Leafe
http://chipy.org/EdOnDabo.
Please ping the list to tell us what you want to address in your
lightning talk. Lets try to get
NOTE: This is a special meeting on next Tuesday in addition to our
normal Thursday meeting. Attend both, if you can.
Tuesday. November 14 2006. 5:30 pm.
Topics
--
Ed Leaf on Dabo is an open-source framework for developing desktop
(i.e., rich client) applications in Python.
Details
Thurs. October 12th, 2006. 7pm.
This will be our best meeting, yet.
David Beasley http://www.dabeaz.com, software developer, writer, and
jazz musician will present on PLY. It's 100% Python and very cool. Do
not miss this one!
Topics
--
* PLY (Python Lex Yacc) David Beazley
* Performance
Thurs. October 12th, 2006. 7pm.
This will be our best meeting, yet.
David Beasley http://www.dabeaz.com, software developer, writer, and
jazz musician will present on PLY. It's 100% Python and very cool. Do
not miss this one!
Topics
--
* PLY (Python Lex Yacc) David Beazley
* Performance
09-18-2006
Announcing Zenoss Version 0.22.3
All,
Version 0.22.3 of Zenoss is available for download. Version 0.22.3 is
a dot release of version 0.22.0, which added several new features,
including:
* Support for Nagios Plugins (zenagios)
* Addition of a GUI for the selection of Alerting
Chicago Python User Group
=
Come join us for our best meeting ever!
Topics
--
* Google Code (Brian Fitzpatrick and Ben Collins-Sussman)
* Trac + Subversion + doctests (Garrett Smith)
* Special method names for operator overloading (Brian Ray)
Location
Chicago Python User Group
=
Come join us for our best meeting ever!
Topics
--
* Google Code (Brian Fitzpatrick and Ben Collins-Sussman)
* Trac + Subversion + doctests (Garrett Smith)
* Special method names for operator overloading (Brian Ray)
Location
This will be our best meeting yet! ChiPy's Monthly meeting this Thurs.
August 10, 2006. 7pm. (except for folks who want to help setup at 6:30
and get first dibs on pizza-compliments of Uncle Roy (Singham))
Topics
--
* Adrian Holovaty's new Django Add-on for quickly publishing websites.
*
This will be our best meeting yet! ChiPy's Monthly meeting this Thurs.
August 10, 2006. 7pm. (except for folks who want to help setup at 6:30
and get first dibs on
pizza-compliments of Uncle Roy (Singham))
Topics
--
* Adrian Holovaty's new Django Add-on for quickly publishing websites.
*
101 - 200 of 203 matches
Mail list logo
