On Feb 24, 2015, at 10:56 AM, Guido van Rossum gu...@python.org wrote:
It sure seems that way.
Thanks for the additional feedback Guido. I’d spent some further time thinking
about what it was that I was looking for and determined it was bollocks. The
proposal was a poor solution to a
On Feb 20, 2015, at 7:03 PM, Ian Cordasco graffatcolmin...@gmail.com wrote:
I hope this helps.
It does, as do the other replies, thanks all. To be clear, my first gripe has
stemmed into two related (but very minor) problems:
1. IntEnum.__str__. I understand the reasoning behind the current
While working on a bug in the issue tracker, I came across something that I
thought was a little odd around the behaviour of IntEnum. Should the behaviour
of an instance of an IntEnum not be symmetric to an int where possible? For
example:
class MyEnum(IntEnum):
... FOO = 1
...
On Feb 20, 2015, at 8:54 AM, Brett Cannon br...@python.org wrote:
Concrete reason. The string is 'MyEnum.FOO' which is much more readable and
obvious where the value came from. The fact that it can be treated as an int
is the same as the reason True and False are subclasses of int; it made
On 2015-01-24 7:17 AM, Donald Stufft wrote:
It’s not just power users that it’s good for, it makes it harder for
even beginners to use things like backports of modules.
What about cases where new module versions are put in as dependencies of
other packages and they stomp standard library
On 2015-01-14 11:35 AM, Guido van Rossum wrote:
Why do you want to hack the existing http modules?
This is not a rhetorical question. The answer may lead us to redesign the
existing http modules to be more flexible so that the higher-level problem
you are trying to solve by hacking http
On 2015-01-14 12:25 PM, Guido van Rossum wrote:
I'm not sure how commit privileges would help you -- can't you just fork
the CPython (I'm sure there's already a Bitbucket mirror that you can fork
easily) and do your work there? Even with commit privileges you wouldn't be
committing partial
On 2015-01-14 1:19 PM, Brett Cannon wrote:
But as Guido pointed out, we _like_ it being difficult to do because we
don't want this kind of substitution happening as code ends up depending on
bugs and quirks that you may fix.
I can understand the reasoning.
How many other modules are
with that as this is a very specific use case:
Having imports across tests and package modules use httplib3 to
facilitate merging changes back upstream.
On 2015-01-14 8:32 AM, Demian Brecht wrote:
Hi all,
As part of the work I'm doing on httplib3 (now that I've actually gotten
a bit of time), one of the things I'm
Hi all,
As part of the work I'm doing on httplib3 (now that I've actually gotten
a bit of time), one of the things I'm trying to get done is injection of
httplib3 over http in order to not have to modify all import paths in
modules and such. Here's the gist of what I have so far:
Hi all,
As part of the work I'm doing on httplib3 (now that I've actually gotten
a bit of time), one of the things I'm trying to get done is injection of
httplib3 over http in order to not have to modify all import paths in
modules and such. Here's the gist of what I have so far:
I had considered that but thought that dev might be more appropriate as
it's related to overriding a stdlib module in order to work on that module
out of band with cpython (with the intention of merging back upstream). I
would imagine those on the dev list may be better suited to answer.
On Wed,
Hm, I /did/ try that but ran into issues. Swapping the custom finder for
the monkey patch now seems to work as expected though. Could be that I
was doing something else at the time that caused it not to work.
I'll keep running with that and will ping the thread if the issues
surface again.
It denotes a variadic function:
http://www.gnu.org/software/libc/manual/html_node/Variadic-Functions.html.
On 2015-01-07 11:07 AM, Ethan Furman wrote:
I found this:
PyObject *
PyBytes_FromFormat(const char *format, ...)
{
Can someone enlighten me on what the '...' means?
--
On Tue, Dec 2, 2014 at 9:23 AM, Tres Seaver tsea...@palladion.com wrote:
I'd vote for experimentation, to ground the discussion in actual practice.
+1. There may be a number of practical gotchas that very well might
not surface in PEPs and should be documented and planned for. Likewise
with
://mail.python.org/mailman/options/python-dev/demianbrecht%40gmail.com
--
Demian Brecht
https://demianbrecht.github.io
https://github.com/demianbrecht
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
On Sat, Nov 29, 2014 at 3:27 PM, Donald Stufft don...@stufft.io wrote:
As promised in the Move selected documentation repos to PSF BitBucket
account? thread I've written up a PEP for moving selected repositories
from
hg.python.org to Github.
FWIW, I'm a pretty solid -1 to this PEP.
Don't get
On Tue, Nov 25, 2014 at 6:52 AM, Brett Cannon br...@python.org wrote:
I suspect if we make sure we add Bitbucket and GitHub login support to the
issue tracker then that would help go a fair distance to helping with the
GitHub pull of reach (and if we make it so people can simply paste in
docs is standard throughout the stdlib. Is
there an actual reason for this?
Thanks,
--
Demian Brecht
http://demianbrecht.github.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
ensure that the same docs are available (and consistent) when reading
the documentation as well as when neck-deep in code.
On Sun, May 19, 2013 at 3:32 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 19 May 2013 15:29:37 -0700
Demian Brecht demianbre...@gmail.com wrote:
This is more out
:
On 20 May 2013 08:51, Demian Brecht demianbre...@gmail.com wrote:
@benjamin: Ah, i see. I wasn't around pre-Sphinx. However, unless
there's some custom build steps that I'm unaware of that may prevent
it, it should still be relatively easy to maintain the desired
narrative structure as long
On 2013-03-11 5:44 AM, R. David Murray wrote:
though some patience
and persistence may be required.
I have a wife and kids. This, I've become quite good at ;)
Take a look at http://bugs.python.org/issue2193 (for example), and see
if you still want to tackle this topic :) (I hope you do).
On 2013-03-10 1:59 PM, R. David Murray wrote:
To be clear, just passing the stdlib tests is*not* sufficient to think
that backward compatibility is not likely to be broken. Deciding about
the likelihood of breakage is a hard problem, to which we generally
employ gut-level heuristics:) (And
On 2013-03-10 2:36 PM, Terry Reedy wrote:
A) For similar reasons, I consider the proposal a first draft, and
probably not the exact right thing to do.
That is correct. The more I think about it, the more I'm convincing
myself that even though the proposal is more sane than what's there
right
even
though it might not make sense, keep the old implementations around
and deprecate them to be eventually replaced by the processors, or
other ideas?
--
Demian Brecht
http://demianbrecht.github.com
___
Python-Dev mailing list
Python-Dev@python.org
Sounds good to me, thanks for the feedback.. Yes, I guess tackling
known issues is a much better use of time than trying to dig my own up
;)
If you want to be helpful, leave _parse along and find a real bug to work on
;-). There are several urllib bug issues. Or check out the code coverage of
I'm off my rocker ;)
Also, are contributor agreements also required for documentation?
Thanks,
Demian Brecht
http://demianbrecht.github.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
27 matches
Mail list logo