Hi all,
I'm not sure whether this should be python-list or here, but given it's a
premature code review for http.client, I figured I'd post here first.
I'm in the process of adding support for chunked transfer encoding to
http.client (issue #12319). One of the bits of functionality that I'm wor
> On Feb 24, 2015, at 10:56 AM, Guido van Rossum 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 specific immediate pro
>
> On Feb 20, 2015, at 7:03 PM, Ian Cordasco 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
implementation. Persona
> On Feb 20, 2015, at 8:54 AM, Brett Cannon 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
> practical
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
...
>>> MyEn
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 packa
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 depen
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 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
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.
Thanks
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, J
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
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:
https://gist.gith
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:
https://gist.gith
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 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 benefits.
___
python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/demianbrecht%40gmail.com
--
Demian Brecht
https://demianbrecht.github.io
https://github.com/demianbrecht
__
On Sat, Nov 29, 2014 at 3:27 PM, Donald Stufft 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 me wrong, I
On Tue, Nov 25, 2014 at 6:52 AM, Brett Cannon 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 their
> fork's
wrote:
>
> On 20 May 2013 08:51, "Demian Brecht" 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
when desired. This would
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 wrote:
> On Sun, 19 May 2013 15:29:37 -0700
> Demian Brecht wrote:
>> This is more
seems like external 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-de
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).
E
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
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 cod
o I'm not entirely
sure what best practice is around that: leave well enough alone 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
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
to change this to use one of the aforementioned
functions and submit a patch, but wanted to see if there was any
rational behind this that I wasn't seeing.
Yes, it's a very minor issue. Call me a stickler for things like this :)
--
Demian Brecht
http://dem
maybe 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/
29 matches
Mail list logo
