Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.
On Fri, May 29, 2015 at 4:14 PM, Gregory P. Smith g...@krypto.org wrote: On Fri, May 29, 2015 at 12:24 AM Nick Coghlan ncogh...@gmail.com wrote: On 29 May 2015 11:01 am, Victor Stinner victor.stin...@gmail.com wrote: Why not continue to enhance Python 3 instead of wasting our time with Python 2? We have limited resources in term of developers to maintain Python. (I'm not talking about fixing *bugs* in Python 2 which is fine with me.) I'm actually OK with volunteers deciding that even fixing bugs in 2.7 isn't inherently rewarding enough for them to be willing to do it for free on their own time. That is 100% okay. What is not okay is for python-dev representatives to respond to users (in any list/forum/channel) reporting bugs in 2.7 or asking if a fix in 3 can be backported to 2.7 with things akin to just use Python 3 or sorry, 2.7 is critical fixes only. move to python 3 already. This is actively driving our largest users away. I bring this up because a user was bemoaning how useless they feel python core devs are because of this attitude recently. Leading to feelings of wishing to just abandon CPython if not Python all together. I'm sure I have even made some of those responses myself (sorry!). My point here is: know it. recognize it. don't do it anymore. It harms the community. A correct and accurate response to desires to make non-api-breaking changes in 2.7 is Patches that do not change any APIs for 2.7 are welcome in the issue tracker. possibly including I don't have the bandwidth to review 2.7 changes, find someone on python-dev to review and champion this for you if you need it. Finding someone may not always be easy. But at least is still the patches welcome attitude and suggests that the work can be done if someone is willing to do it. Lets make a concerted effort to not be hostile and against it by default. Ex: Is someone with a python application that is a million of lines supposed to have everyone involved in that drop the productive work they are doing and spend that porting their existing application to python 3 because we have so far failed to provide the tools to make that migration easy? No. Empathize with our community. Feel their pain. (and everyone who is working on tools to aid the transition: keep doing that! Our users are gonna need it unless we don't want them as users anymore.) We committed to supporting 2.7 until 2020 in 2014 per https://hg.python.org/peps/rev/76d43e52d978. That means backports of important bug or performance fixes should at least be allowed on the table, even if hairy, even if you won't work on them yourselves on a volunteer basis. This is the first long term support release of Python ever. This is what LTS means. LTS could also stand for Learn To Support... At the same time, they can ask for it, but if people aren't motivated to do the work for it, it won't happen. We should be encouraging (and maybe even mentoring) these people who are desperately in need of the fixes to be backported, to backport the patches themselves. With that done, it can go through review and we can maybe get those fixes in faster if we can also get a larger group of reviews. The problem consists of a few parts: - We're all volunteers - Volunteers are going to work on what interests them - Python 2.7 maintenance doesn't seem to interest many of our volunteers currently Perhaps we should explain this to each of the people requesting backports to (ideally) encourage them. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.
On Fri, May 29, 2015 at 6:04 PM, Guido van Rossum gu...@python.org wrote: On Fri, May 29, 2015 at 2:52 PM, Ian Cordasco graffatcolmin...@gmail.com wrote: On Fri, May 29, 2015 at 4:14 PM, Gregory P. Smith g...@krypto.org wrote: On Fri, May 29, 2015 at 12:24 AM Nick Coghlan ncogh...@gmail.com wrote: On 29 May 2015 11:01 am, Victor Stinner victor.stin...@gmail.com wrote: Why not continue to enhance Python 3 instead of wasting our time with Python 2? We have limited resources in term of developers to maintain Python. (I'm not talking about fixing *bugs* in Python 2 which is fine with me.) I'm actually OK with volunteers deciding that even fixing bugs in 2.7 isn't inherently rewarding enough for them to be willing to do it for free on their own time. That is 100% okay. What is not okay is for python-dev representatives to respond to users (in any list/forum/channel) reporting bugs in 2.7 or asking if a fix in 3 can be backported to 2.7 with things akin to just use Python 3 or sorry, 2.7 is critical fixes only. move to python 3 already. This is actively driving our largest users away. I bring this up because a user was bemoaning how useless they feel python core devs are because of this attitude recently. Leading to feelings of wishing to just abandon CPython if not Python all together. I'm sure I have even made some of those responses myself (sorry!). My point here is: know it. recognize it. don't do it anymore. It harms the community. A correct and accurate response to desires to make non-api-breaking changes in 2.7 is Patches that do not change any APIs for 2.7 are welcome in the issue tracker. possibly including I don't have the bandwidth to review 2.7 changes, find someone on python-dev to review and champion this for you if you need it. Finding someone may not always be easy. But at least is still the patches welcome attitude and suggests that the work can be done if someone is willing to do it. Lets make a concerted effort to not be hostile and against it by default. Ex: Is someone with a python application that is a million of lines supposed to have everyone involved in that drop the productive work they are doing and spend that porting their existing application to python 3 because we have so far failed to provide the tools to make that migration easy? No. Empathize with our community. Feel their pain. (and everyone who is working on tools to aid the transition: keep doing that! Our users are gonna need it unless we don't want them as users anymore.) We committed to supporting 2.7 until 2020 in 2014 per https://hg.python.org/peps/rev/76d43e52d978. That means backports of important bug or performance fixes should at least be allowed on the table, even if hairy, even if you won't work on them yourselves on a volunteer basis. This is the first long term support release of Python ever. This is what LTS means. LTS could also stand for Learn To Support... At the same time, they can ask for it, but if people aren't motivated to do the work for it, it won't happen. We should be encouraging (and maybe even mentoring) these people who are desperately in need of the fixes to be backported, to backport the patches themselves. With that done, it can go through review and we can maybe get those fixes in faster if we can also get a larger group of reviews. The problem consists of a few parts: - We're all volunteers Speak for yourself. There are a fair number of people on this thread whose employer pays them to work on Python. And this thread originated when a patch was being contributed by people who were also paid by their employer to do all the dirty work (including benchmarks). And yet they were (initially) given the cold shoulder by some high and mighty Python 3 zealots. This attitude need to change. - Volunteers are going to work on what interests them - Python 2.7 maintenance doesn't seem to interest many of our volunteers currently Perhaps we should explain this to each of the people requesting backports to (ideally) encourage them. Please let someone else do the explaining. I don't want to have to do the damage control after you explain something. Good to know. I'll stop trying to make spare time to review patches then. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)
On Thu, May 28, 2015 at 5:08 PM, Paul Sokolovsky pmis...@gmail.com wrote: Hello, On Thu, 28 May 2015 23:48:59 +0200 Matthias Klose d...@ubuntu.com wrote: [] And the very same place where you are working is investing in getting shared libraries working for Go. Single binaries may be popular for distributing end user applications, but definitely not for distributing a core OS or a SDK. Sorry, you didn't yet arrive in distro land ... Of course it did. Like, Ubuntu 14.04LTS ships Go 1.2. No, it starts with the fact that when you don't have Go installed and type go, it suggests to install gccgo, which just segfaults on running. Then you figure out that you need to install golang, and that's 1.2, and a lot of things simply don't work with that version, like go get reports that a package not found, while it perfectly exists. So, let Go stay what it is - a corporate toy lingo for press-releases. That's until Google has thought that it generated enough buzz and it's time to shut it down like their numerous other projects. (Isn't Go old already and everyone uses Rust?) -- Best regards, Paul mailto:pmis...@gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com Note that as much as I love Rust, it still isn't the replacement for Go. It doesn't have a stable ABI so if you distribute a binary and that person has a different version of Rust 1.x installed, it won't be guaranteed to work (and, at this point, probably won't work anyway). Go is just more popular because it's been around longer and it (as far as a single developer is concerned) gets rid of the dependency mess. That's why developers like it. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Free lists
On May 9, 2015 5:07 PM, Serhiy Storchaka storch...@gmail.com wrote: On 09.05.15 22:51, Larry Hastings wrote: On 05/09/2015 12:01 PM, Serhiy Storchaka wrote: Here is a statistic for most called PyObject_INIT or PyObject_INIT_VAR for types (collected during running Python tests on 32-bit Linux). Can you produce these statistics for a 64-bit build? Sorry, no. All my computers are ran under 32-bit Linux. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com Can you share how you gathered them so someone could run them on a 64-bit build? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] typeshed for 3rd party packages
On Wed, Apr 22, 2015 at 11:12 AM, Skip Montanaro skip.montan...@gmail.com wrote: On Wed, Apr 22, 2015 at 10:43 AM, Guido van Rossum gu...@python.org wrote: For Requests, it looks like it may be better not to have stubs at all. Can you expand on this? Why would Requests be any different than any other module/package? On a separate thread Cory provided an example of what the hints would look like for *part* of one function in the requests public functional API. While our API is outwardly simple, the values we accept in certain cases are actually non-trivially represented. Getting the hints *exactly* correct would be extraordinarily difficult. As for versioning, I think stub files would absolutely have to declare the appropriate version(s) to which they apply (probably via embedded directives), so type checkers can ignore them when necessary. That also means that type checkers must be able to figure out the version of the package used by the application being analyzed. Not sure I'm being too clear, so I will provide an example. I have app myapp which imports module yourmod v 1.2.7. The yourmod author hasn't yet provided type annotations, so someone else contributed a stub to the typeshed. Time passes and a new version of yourmod comes out, v 2.0.0. (Semantic versioning tells us the API has changed in an incompatible way because of the major version bump.) I decide I need some of its new features and update myapp. There is no new stub file in the typeshed yet. When I run my fancy type checker (someone suggested I will shortly have 50 to choose from!), it needs to recognize that the stub no longer matches the version of yourmod I am using, and must ignore it. Which of course also assumes that the author of that library is even using Semantic Versioning (which is not a universal release strategy, even in the Ruby community). I understand where you're coming from, but I think this is a reason as to why typeshed as a catch-all for third party type-hints may not be feasible. Does that suggest the typeshed needs some sort of structure which allows all versions of stubs for the same package to be gathered together? My apologies if I'm following along way behind the curve. No need to apologize. =) As the other maintainer of requests, I think having hints *might* help some developers, but looking at what Cory generated (which looks to be valid), I'm wondering about something else with Type Hints. I've heard several people say Just create an aliased type for the hint so it's shorter! but doesn't that mean we then have to document that alias for our users? I mean if the IDE suggests that the developer use XYZ for this parameter and there's no explanation for XYZ actually is (in the IDE), doesn't this just add a lot more maintenance to adding hints? Maintainers now have to: - Keep the stubs up-to-date - Document the stubs (and if the stubs are in typeshed, does $MyPackage link to the docs in typeshed to avoid users filing bugs on $MyPackage's issue tracker?) - Version the stubs (assuming they're maintained in a third-party location, e.g., typeshed) Don't get me wrong. I really like the idea of moving towards Type Hints. I'm not even particularly against adding type hints for Requests to typeshed. I'm just hesitant that it will be easy to make them entirely accurate. Cheers, Ian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] typeshed for 3rd party packages
On Wed, Apr 22, 2015 at 11:30 AM, Skip Montanaro skip.montan...@gmail.com wrote: On Wed, Apr 22, 2015 at 11:26 AM, Ian Cordasco graffatcolmin...@gmail.com wrote: On a separate thread Cory provided an example of what the hints would look like for *part* of one function in the requests public functional API. Thanks. That encouraged me to look around for recent posts from Cory. Wow... You're welcome! And yeah. That union that Cory posted was for *one* parameter if I remember correctly. I won't speak for Cory, but I'm not against the type hints in 484 but they will be difficult for us as a project. They'll be marginally less difficult for me in a different project of mine. I also wonder about importing type definitions from other packages. The Requests-Toolbelt adds a few features that are enhanced versions of what's already in Requests. I can think of a few type hints that we might create to represent certain parameters, but I don't want to have to copy those for the features in the Requests-Toolbelt. I would expect this to Just Work, but I wonder if anyone else has considered the possibility of this being a need. Cheers, Ian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Mon, Apr 20, 2015 at 4:00 PM, Harry Percival harry.perci...@gmail.com wrote: @Lukasz: Of course you're right, ugly is a matter of perspective, and I'm sure I could grow to love them, and they might evolve into a more polished direction they start to read more transparently after a while. But I'm still worried about beginners, and I'm even worried about me. I like to be able to scan through some code and see the essence of it. I learned Java at school, and I got it figured out, but i'm glad I left it behind. Every so often I read a TDD book and the examples are all in java and it just feels like obfuscation -- public void static private String[] class blabla... so many keywords and types getting in the way of *what the code is actually doing*. That's what's so appealing about Python, it strips it down to just the basics. And, to me, type hints are always going to be some unnecessary chaff that gets in the way of my understanding -- not useless, not that they don't have a purpose or that we should remove them completely. But if there was a way of just hiding them, so that I don't have to think about them, as a beginner, or as a normal programmer, most of the time, in the 90% of cases where I don't need to see them, I shouldn't have to... that's why i'm so keen on this stub files idea. One thing I don't understand is this local variable inference thing -- can that not be made to work in stub files? On 20 April 2015 at 21:50, Harry Percival harry.perci...@gmail.com wrote: stub files are only used to type-check *users* of a module. If you want a module itself to be type-checked you have to use inline type hints is this a fundamental limitation, or just the current state of tooling? On 20 April 2015 at 21:48, Harry Percival harry.perci...@gmail.com wrote: I hate stub files. [...] in my opinion, [it] just about guarantees a maintenance burden that will fall by the side of the road. I'm not so pessimistic. It's not like documentation or docstrings or comments -- the whole point is that it should be very easy to have an automated check for whether your stubs are in sync with your source, because both are in code. Unlike docs or comments which can easily become out of date, because there's no automated process to tell you they need updating... I'm thinking of it as a thing your editor will warn you of. Like pyflakes warnings about unused variables co, I'm never happy until I've silenced them all in a file, and similarly, your editor will keep bugging you until you've got your stubs inline with your code... On 20 April 2015 at 20:37, Isaac Morland ijmor...@uwaterloo.ca wrote: On Mon, 20 Apr 2015, Paul Moore wrote: On 20 April 2015 at 19:41, Barry Warsaw ba...@python.org wrote: tldr; type hints in python source are scary. Would reserving them for stub files be better? I think so. I think PEP 8 should require stub files for stdlib modules and strongly encourage them for 3rd party code. Agreed. I have many of the same concerns as Harry, but I wouldn't have expressed them quite as well. I'm not too worried about actually removing annotations from the core language, but I agree that we should create a strong culture of type hints go in stub files to keep source files readable and clean. On that note, I'm not sure stub files is a particularly good name. Maybe type files would be better? Something that emphasises that they are the correct place to put type hints, not a workaround. How about header files? (ducks...) Isaac Morland CSCF Web Guru DC 2619, x36650 WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/hjwp2%40cantab.net So I've generally stayed out of this but I feel there is some context that people are missing in general. First, allow me to provide some context: I maintain a /lot/ of Python code[1] and nearly all of it is designed to be compatible with Pythons 2.6, 2.7, 3.2, 3.3, 3.4 (and eventually 3.5) and sometimes 2.5 (depending on the project). If I want to improve a developer's experience with some of that code using Type Hints I will essentially have no way to do that unless I write the code with the annotations and ship versions with annotations stripped and other versions with annotations? That's a lot more overhead. If I could provide the annotations in stubs that means that only the people who care about using them will have to use them. Is it more overhead to manage twice the number of files? Yes. Do I feel it would be worth it to not overly complicate how these packages are released? Yes. Further, there are far more reasons to make stubs the baseline (in my opinion) the biggest reason of all is that people want to provide stubs for popular yet unmaintained libraries as third party
Re: [Python-Dev] Aprender Pythton
On Tue, Apr 14, 2015 at 7:54 PM, Andrew Svetlov andrew.svet...@gmail.com wrote: Python-dev is for development OF Python, not for development WITH Python or Python LEARNING, BTW. On Tue, Apr 14, 2015 at 8:46 PM, Raúl Cumplido raulcumpl...@gmail.com wrote: Hi Andrew, Is someone asking where to find resources to learn Python. We have redirected him to the python lists both in english and spanish. We should have replied in English if it would have been something related to python-dev, but we have responded in Spanish as maybe the user doesn't understand English. Kind Regards, Raúl 2015-04-14 20:41 GMT-04:00 Andrew Svetlov andrew.svet...@gmail.com: I'm sorry. Please use English in the mailing list. People may not understand your chatting. 2015-04-14 20:36 GMT-04:00 Erik Rivera erik.ri...@gmail.com: Baldomero, Veo que perteneces al estado de Puebla, México, existe la lista de Python México https://mail.python.org/mailman/listinfo/python-mx, habemos varios de Puebla que te podemos apoyar. Saludos. El 14 de abril de 2015, 19:50, Baldomero Perez martinez bpma...@yahoo.com.dmarc.invalid.mx escribió: Quiero aprender python quiero empezar agradezco si me pueden ayudar L.I. Baldomero Pérez Martínez Enc. Proy. Informatica Fideicomiso Ingenio Atencingo 80326 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/erik.river%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/raulcumplido%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com Andrew if you translate the text that was sent to Baldomero, you'll see that's exactly what they said. Please don't be so rude (or lazy) to people helping someone learn Python, regardless of whether they mistakenly posted to the wrong list. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Prefixes and namespaces
On Sat, Feb 21, 2015 at 1:28 PM, Serhiy Storchaka storch...@gmail.com wrote: /* Namespaces are one honking great idea -- let's do more of those! */ There are two ways to avoid name conflicts: prefixes and namespaces. Programming languages that lacks namespaces (such as C) need to use prefixes. For example: PROTOCOL_SSLv2, PROTOCOL_SSLv3, PROTOCOL_SSLv23. Python used the same prefixed names when reflect C constants to module level Python globals. But when convert integer constants to IntEnum, is it needed to preserve common prefix? Or may be we can drop it, because enum class name plays its role? class Protocol(IntEnum): PROTOCOL_SSLv2 = ... PROTOCOL_SSLv3 = ... PROTOCOL_SSLv23 = ... or class Protocol(IntEnum): SSLv2 = ... SSLv3 = ... SSLv23 = ... ? Protocol.PROTOCOL_SSLv2 or Protocol.SSLv2? So I like the latter (Protocol.SSLv2) but would qualify that with the request that ssl.PROTOCOL_SSLv2 continue to work until Python 2 is dead and libraries like requests, urllib3, httplib2, etc. no longer need to support those versions. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: str(IntEnum)
On Fri, Feb 20, 2015 at 12:36 PM, Florian Bruhin m...@the-compiler.org wrote:
* Demian Brecht demianbre...@gmail.com [2015-02-20 10:24:53 -0800]:
These and other implementations return a string representation of the
instance’s value, not a string representation of the object itself. Whereas
elsewhere in the standard library:
str(ProtocolError('url', 42, 'msg', ''))
'ProtocolError for url: 42 msg’
str(URLError('reason'))
'urlopen error reason’
str(Cookie(0, '', '', '4', '', '', '', '', '', '', '', 0, '', '', '',
''))
'Cookie = for :4'
The specific problem that I encountered was when swapping an IntEnum
implementation for ints in http.client, which caused a change in logging
output (from int.__str__ to Enum.__str__) , which was a bit of a surprise,
especially given the value is a builtin type.
I think that a decent rule around the usage of __str__ is that it should be
a string representation of the value, not of the object. Failing the ability
to logically coerce the value to a string, it should simply fall back to
repr(obj).
Of course, I realize that the chances of this change being made to such a
fundamental (and largely inconsequential) feature are likely nil, but I
thought I’d share my thoughts anyways.
foo = object()
str(foo)
'object object at 0x7f799a8a9070'
repr(foo)
'object object at 0x7f799a8a9070'
This is exactly what you see above. ;)
Florian
--
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
I love long mails! | http://email.is-not-s.ms/
There's a semantic difference between an int and an IntEnum (or
subclass thereof). MyEnum.FOO is a MyEnum type. IntEnums just happen
to behave like an int under certain circumstances. That doesn't mean
it needs to act like it in all. Further, it can be turned into an int
if you want to represent it as an int, e.g., str(int(MyEnum.FOO)) ==
str(1). I hope this helps.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PyPI] Why are some packages on pypi.python.org/simple, but have no page?
Taking one of your examples: https://pypi.python.org/simple/acid/ 404s (I didn't bother checkin the other three). So there are links on /simple but no content for them. So I think your question is better asked, why are there links on /simple that lead to 404s. On Sun, Jan 18, 2015 at 9:08 AM, Martin Thoma i...@martin-thoma.de wrote: Hello Python developers, Could anybody please answer the following question? (I have asked it on http://stackoverflow.com/q/28010799/562769, but Steve Barnes thinks I should ask it here) I am currently analyzing packages on PyPI. I use https://pypi.python.org/simple/ to get all package names and https://pypi.python.org/pypi/numpy/json and similar to get the metadata. However, there are 514 packages (e.g. abu.rpc, acid, about-pandoc, about-numtest, ...) which do not have the https://pypi.python.org/pypi/ site, but are on https://pypi.python.org/simple/. Why is that the case? Best regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Overriding stdlib http package
I think this belongs on python-list, not python-dev. On Wed, Jan 14, 2015 at 10:32 AM, Demian Brecht demianbre...@gmail.com 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 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.github.com/demianbrecht/bc6530a40718e4fcbf90. It's greatly simplified over importlib2's inject mechanism, but I'm assuming that's largely due to requirements of that package (i.e. Python 2) in contrast to this one. My questions are: Does this look sane? Is there anything that I might be not accounting for? It /does/ seem to work as expected when running tests, but I'm curious if there's anything that I might be missing that might jump out at someone more intimately familiar with the mechanics of importlib. Thanks, Demian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
On Wed, Dec 10, 2014 at 11:10 AM, Donald Stufft don...@stufft.io wrote: On Dec 10, 2014, at 11:59 AM, Bruno Cauet brunoca...@gmail.com wrote: Hi all, Last year a survey was conducted on python 2 and 3 usage. Here is the 2014 edition, slightly updated (from 9 to 11 questions). It should not take you more than 1 minute to fill. I would be pleased if you took that time. Here's the url: http://goo.gl/forms/tDTcm8UzB3 I'll publish the results around the end of the year. Last year results: https://wiki.python.org/moin/2.x-vs-3.x-survey Just going to say http://d.stufft.io/image/0z1841112o0C is a hard question to answer, since most code I write is both. The same holds for me. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My thinking about the development process
On Dec 5, 2014 4:18 PM, Eric Snow ericsnowcurren...@gmail.com wrote: Very nice, Brett. On Fri, Dec 5, 2014 at 1:04 PM, Brett Cannon bcan...@gmail.com wrote: And we can't forget the people who help keep all of this running as well. There are those that manage the SSH keys, the issue tracker, the review tool, hg.python.org, and the email system that let's use know when stuff happens on any of these other systems. The impact on them needs to also be considered. It sounds like Guido would rather as much of this was done by a provider rather than relying on volunteers. That makes sense though there are concerns about control of certain assents. However, that applies only to some, like hg.python.org. ## Contributors I see two scenarios for contributors to optimize for. There's the simple spelling mistake patches and then there's the code change patches. The former is the kind of thing that you can do in a browser without much effort and should be a no-brainer commit/reject decision for a core developer. This is what the GitHub/Bitbucket camps have been promoting their solution for solving while leaving the cpython repo alone. Unfortunately the bulk of our documentation is in the Doc/ directory of cpython. While it's nice to think about moving the devguide, peps, and even breaking out the tutorial to repos hosting on Bitbucket/GitHub, everything else is in Doc/ (language reference, howtos, stdlib, C API, etc.). So unless we want to completely break all of Doc/ out of the cpython repo and have core developers willing to edit two separate repos when making changes that impact code **and** docs, moving only a subset of docs feels like a band-aid solution that ignores the big, white elephant in the room: the cpython repo, where a bulk of patches are targeting. With your ideal scenario this would be a moot point, right? There would be no need to split out doc-related repos. For the code change patches, contributors need an easy way to get a hold of the code and get their changes to the core developers. After that it's things like letting contributors knowing that their patch doesn't apply cleanly, doesn't pass tests, etc. This is probably more work than it seems at first. As of right now getting the patch into the issue tracker is a bit manual but nothing crazy. The real issue in this scenario is core developer response time. ## Core developers There is a finite amount of time that core developers get to contribute to Python and it fluctuates greatly. This means that if a process can be found which allows core developers to spend less time doing mechanical work and more time doing things that can't be automated -- namely code reviews -- then the throughput of patches being accepted/rejected will increase. This also impacts any increased patch submission rate that comes from improving the situation for contributors because if the throughput doesn't change then there will simply be more patches sitting in the issue tracker and that doesn't benefit anyone. This is the key concern I have with only addressing the contributor side of things. I'm all for increasing contributions, but not if they are just going to rot on the tracker and we end up with disillusioned contributors. # My ideal scenario If I had an infinite amount of resources (money, volunteers, time, etc.), this would be my ideal scenario: 1. Contributor gets code from wherever; easiest to just say fork on GitHub or Bitbucket as they would be official mirrors of hg.python.org and are updated after every commit, but could clone hg.python.org/cpython if they wanted 2. Contributor makes edits; if they cloned on Bitbucket or GitHub then they have browser edit access already 3. Contributor creates an account at bugs.python.org and signs the CLA There's no real way around this, is there? I suppose account creation *could* be automated relative to a github or bitbucket user, though it probably isn't worth the effort. However, the CLA part is pretty unavoidable. 3. The contributor creates an issue at bugs.python.org (probably the one piece of infrastructure we all agree is better than the other options, although its workflow could use an update) I wonder if issue creation from a PR (where no issue # is in the message) could be automated too without a lot of extra work. 4. If the contributor used Bitbucket or GitHub, they send a pull request with the issue # in the PR message 5. bugs.python.org notices the PR, grabs a patch for it, and puts it on bugs.python.org for code review 6. CI runs on the patch based on what Python versions are specified in the issue tracker, letting everyone know if it applied cleanly, passed tests on the OSs that would be affected, and also got a test coverage report 7. Core developer does a code review 8. Contributor updates their code based on the code review and the updated
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, Nov 30, 2014 at 7:01 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 30 Nov 2014 16:23:08 +1100 Chris Angelico ros...@gmail.com wrote: Yes, GitHub is proprietary. But all of your actual code is stored in git, which is free, and it's easy to push that to a new host somewhere else, or create your own host. This proposal is for repositories that don't need much in the way of issue trackers etc, so shifting away from GitHub shouldn't demand anything beyond moving the repos themselves. I hope we're not proposing to move the issue trackers to github, otherwise I'm -1 on this PEP. Regards Antoine. So I usually choose not to weigh in on discussions like these but there seems to be a lot of misdirection in some of these arguments. To start, I'm generally neutral about this proposal or Nick's proposal that spurred this one. I've found the most frustrating part of contributing to anything involving CPython to be the lack of reviewer time. I have had very small (2-line) patches take months (close to a year in reality) to get through in spite of periodically pinging the appropriate people. Moving to git/GitHub will not alleviate this at all. To be clear, the main reasoning behind Nick's was being able to submit changes without ever having to have a local copy of the repository in question on your machine. Having a complete web workflow for editing and contributing makes the barrier to entry far lower than switching VCS or anything else. BitBucket (apparently, although I've never used this) and GitHub both have this capability and *both* are free-as-in-beer systems. No one as I understand it is proposing that we use the per-distro proprietary interface to these websites. All data can be removed from GitHub using it's API and can generally be converted to another platform. The same goes for BitBucket although it's arguably easier to retrieve issue data from BitBucket than GitHub. That said, *the issue tracker is not covered by these proposals* so this is a moot point. Drop it already. If we're seriously considering moving to git as a DVCS, we should consider the real free-as-in-freedom alternatives that come very close to GitHub and can be improved by us (even though they're not written in Python). One of those is GitLab. We can self-host a GitLab instance easily or we can rely on gitlab.com. GitLab aims to provide a very similar user experience to GitHub and it's slowly approaching feature parity and experience parity. GitLab is also what a lot of people chose to switch to after the incident Steven mentioned, which I don't think is something we should dismiss or ignore. We should refocus the discussion with the following in mind: - Migrating data from GitHub is easy. There are free-as-in-freedom tools to do it and the only cost is the time it would take to monitor the process - GitHub has a toxic company culture that we should be aware of before moving to it. They have a couple blog posts about attempting to change it but employees became eerily silent after the incident and have remained so from what I've personally seen. - GitHub may be popular but there are popular FOSS solutions that exist that we can also self-host at something like forge.python.org - bugs.python.org is not covered by any of these proposals - The main benefit this proposal (and the proposal to move to BitBucket) are seeking to achieve is an online editing experience allowing for *anyone with a browser and an account* to contribute. This to me is the only reason I would be +1 for either of these proposals (if we can reach consensus). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Nov 30, 2014 11:09 AM, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 11:55 AM, Barry Warsaw ba...@python.org wrote: On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote: - Migrating data from GitHub is easy. There are free-as-in-freedom tools to do it and the only cost is the time it would take to monitor the process *Extracting* data may be easy, but migrating it is a different story. As the Mailman project has seen in trying to migrate from Confluence to Moin, there is a ton of very difficult work involved after extracting the data. Parsing the data, ensuring that you have all the bits you need, fitting it into the new system's schema, working out the edge cases, adapting to semantic differences and gaps, ensuring that all the old links are redirected, and so on, were all exceedingly difficult[*]. Even converting between two FLOSS tools is an amazing amount of work. Look at what Eric Raymond did with reposurgeon to convert from Bazaar to git. I fail to see how this is a reasonable argument to make at all since, as you mentioned, converting between two FLOSS tools can be an amazing amount of work. Realistically the amount of work is going to be predicated on whether or not there is a tool that already handles the conversion for you. Assuming of course that the data is available to you at all. As a particularly relevant example, switching from Mercurial to Git is as easy as installing hg-git, creating a bookmark for master that tracks default, and then pushing to a git repository. It's a good thing that your data isn't locked behind a proprietary door, for now. That's only part of the story. But also, because github is a closed system, there's no guarantee that today's data-freeing APIs will still exist, continue to be functional for practical purposes, remain complete, or stay at parity with new features. This feels like Chicken Little-ing. If Github closed it’s APIs then you could still get at that data by scraping the web interface. However why would Github do that? That would piss off the vast majority of OSS projects who are currently hosted there and is likely to cause a pretty big migration off of Github for fear that Github is going to attempt to lock people onto Github. The popularity of Github *is* Github’s killer feature and doing something that is going to send the vast bulk of your users running for the hills sounds like something that they would have to be particularly stupid to do. Cheers, -Barry [*] And our huge gratitude goes to Paul Boddie for his amazing amount of work on the project. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA I tend to agree with Donald that it's highly unlikely for GitHub to close off their APIs but Barry is right that it isn't impossible. That can be mitigated by regularly scheduling a back-up of that data using the tools we have now so that the sky doesn't appear to be falling if the worst case does occur. I also tend to disagree with Barry that it will be extraordinarily difficult because I have migrated issues and pull requests off of GitHub and was able to automate the entirety of it reliably with python. Admittedly, I'm very familiar with GitHub's API as the author of github3.py so for me this is a trivial task. I would also be willing to help set up migrations and back ups if we decide to use GitHub. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Can this discussion be split off into a separate discussion. It's tangential to the PEP and clearly not actively progressing so it doesn't seem productive. I don't care where it's taken, but I don't think this belongs here. Speculation on the actions of the msysgit project are not fair talk for this PEP. On Sun, Nov 30, 2014 at 12:14 PM, Paul Moore p.f.mo...@gmail.com wrote: On 30 November 2014 at 16:08, Donald Stufft don...@stufft.io wrote: On Nov 30, 2014, at 7:31 AM, Paul Moore p.f.mo...@gmail.com wrote: On 29 November 2014 at 23:27, Donald Stufft don...@stufft.io wrote: In previous years there was concern about how well supported git was on Windows in comparison to Mercurial. However git has grown to support Windows as a first class citizen. In addition to that, for Windows users who are not well aquanted with the Windows command line there are GUI options as well. I have little opinion on the PEP as a whole, but is the above statement true? From the git website, version 2.2.0 is current, and yet the downloadable Windows version is still 1.9.4. That's a fairly significant version lag for a first class citizen. I like git, and it has a number of windows-specific extensions that are really useful (more than Mercurial, AFAIK), but I wouldn't say that the core product supported Windows on an equal footing to Linux. Paul I think so yes. I may be wrong, however while 1.9.4 may be the latest downloadable version of git for Windows, there is no downloadable version of the Linux clients at all, they just tell you to go use your package manager which for instance is version 1.7 on Debian. On OS X the latest version is 2.0.1. OTOH, presumably you can build your own copy of git from source on Linux/OSX. I haven't tried this on Windows but it looks pretty difficult (you start by downloading the msysgit development environment and go from there). Also, if it's easy to produce binaries for 2.2.0 on Windows, why haven't the msysgit project (still an external project, to an extent, AFAICT) done so? Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding numbering to PEP 20, the Zen of Python
On Thu, Sep 18, 2014 at 8:30 PM, Ben Hoyt benh...@gmail.com wrote: I was emailing someone today about implementing something (for PEP 471, as it happens) and wanted to link to the Zen of Python [1] and note a particular clause (in this case If the implementation is hard to explain, it's a bad idea.). However, there are no clause numbers, so you can't refer to specific phrases. I know it's a short enough document that it probably doesn't matter. And maybe numbering them would make it less Zen. Would be handy in code reviews and the like, for example: Not very Pythonic. See PEP 20 point 5. Is it just my pedantic self, or have others wanted to do this too? [1] http://legacy.python.org/dev/peps/pep-0020/ -Ben ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com It's just you I think. Also, isn't this better suited for python-ideas? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pip enhancement
On Wed, Aug 27, 2014 at 8:24 AM, Paul Moore p.f.mo...@gmail.com wrote: On 27 August 2014 13:58, Neal Becker ndbeck...@gmail.com wrote: At least, pip should have the ability to alert the user to potential updates, pip update could list which packages need updating, and offer to perform the update. I think this would go a long way to helping with this problem. Do you mean something like pip list --outdated? Paul Also, isn't this discussion better suited for Distutils-SIG? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)
On Mon, Aug 18, 2014 at 3:22 PM, Benjamin Peterson benja...@python.org wrote: It uses a CACert certificate, which your system probably doesn't trust. On Mon, Aug 18, 2014, at 13:12, Terry Reedy wrote: Firefox does not want to connect to https:bugs.python.org. Plain bugs.python.org works fine. Has the certificate expired? -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/benjamin%40python.org Benjamin that looks accurate. I see the same thing as Terry (on Firefox 31) and the reason is: bugs.python.org uses an invalid security certificate. The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: PEP 467: Minor API improvements for bytes bytearray
On Aug 17, 2014 12:17 PM, Donald Stufft don...@stufft.io wrote: On Aug 17, 2014, at 1:07 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Aug 17, 2014, at 1:41 AM, Nick Coghlan ncogh...@gmail.com wrote: If I see bytearray(10) there is nothing there that suggests this creates an array of length 10 and initialises it to zero to me. I'd be more inclined to guess it would be equivalent to bytearray([10]). bytearray.zeros(10), on the other hand, is relatively clear, independently of user expectations. Zeros would have been great but that should have been done originally. The time to get API design right is at inception. Now, you're just breaking code and invalidating any published examples. Another thought is that the core devs should be very reluctant to deprecate anything we don't have to while the 2 to 3 transition is still in progress. Every new deprecation of APIs that existed in Python 2.7 just adds another obstacle to converting code. Individually, the differences are trivial. Collectively, they present a good reason to never migrate code to Python 3. This is actually one of the inconsistencies between the Python 2 and 3 binary APIs: However, bytearray(n) is the same in both Python 2 and Python 3. Changing it in Python 3 increases the gulf between the two. The further we let Python 3 diverge from Python 2, the less likely that people will convert their code and the harder you make it to write code that runs under both. FWIW, I've been teaching Python full time for three years. I cover the use of bytearray(n) in my classes and not a single person out of 3000+ engineers have had a problem with it. I seriously question the PEP's assertion that there is a real problem to be solved (i.e. that people are baffled by bytearray(bufsiz)) and that the problem is sufficiently painful to warrant the headaches that go along with API changes. The other proposal to add bytearray.byte(3) should probably be named bytearray.from_byte(3) for clarity. That said, I question whether there is actually a use case for this. I have never seen seen code that has a need to create a byte array of length one from a single integer. For the most part, the API will be easiest to learn if it matches what we do for lists and for array.array. Sorry Nick, but I think you're making the API worse instead of better. This API isn't perfect but it isn't flat-out broken either. There is some unfortunate asymmetry between bytes() and bytearray() in Python 2, but that ship has sailed. The current API for Python 3 is pretty good (though there is still a tension between wanting to be like lists and like strings both at the same time). Raymond P.S. The most important problem in the Python world now is getting Python 2 users to adopt Python 3. The core devs need to develop a strong distaste for anything that makes that problem harder. For the record I’ve had all of the problems that Nick states and I’m +1 on this change. I've run into these problems as well, but I'm swayed by Raymond's argument regarding bytearray's constructor. I wouldn't be adverse to adding zeroes (for some parity between bytes and bytearray) to that but I'm not sure deprecating te behaviour of bytearray's constructor is necessary. (Whilst on my phone I only replied to Donald, so I'm forwarding this to the list.) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 467: Minor API improvements for bytes bytearray
On Sun, Aug 17, 2014 at 8:52 PM, Ethan Furman et...@stoneleaf.us wrote: On 08/17/2014 04:08 PM, Nick Coghlan wrote: I'm fine with postponing the deprecation elements indefinitely (or just deprecating bytes(int) and leaving bytearray(int) alone). +1 on both pieces. Perhaps postpone the deprecation to Python 4000 ;) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multiline with statement line continuation
On Tue, Aug 12, 2014 at 7:15 AM, Steven D'Aprano st...@pearwood.info wrote:
On Tue, Aug 12, 2014 at 10:28:14AM +1000, Nick Coghlan wrote:
On 12 Aug 2014 09:09, Allen Li cyberdup...@gmail.com wrote:
This is a problem I sometimes run into when working with a lot of files
simultaneously, where I need three or more `with` statements:
with open('foo') as foo:
with open('bar') as bar:
with open('baz') as baz:
pass
Thankfully, support for multiple items was added in 3.1:
with open('foo') as foo, open('bar') as bar, open('baz') as baz:
pass
However, this begs the need for a multiline form, especially when
working with three or more items:
with open('foo') as foo, \
open('bar') as bar, \
open('baz') as baz, \
open('spam') as spam \
open('eggs') as eggs:
pass
I generally see this kind of construct as a sign that refactoring is
needed. For example, contextlib.ExitStack offers a number of ways to manage
multiple context managers dynamically rather than statically.
I don't think that ExitStack is the right solution for when you have a
small number of context managers known at edit-time. The extra effort of
writing your code, and reading it, in a dynamic manner is not justified.
Compare the natural way of writing this:
with open(spam) as spam, open(eggs, w) as eggs, frobulate(cheese) as
cheese:
# do stuff with spam, eggs, cheese
versus the dynamic way:
with ExitStack() as stack:
spam, eggs = [stack.enter_context(open(fname), mode) for fname, mode in
zip((spam, eggs), (r, w)]
cheese = stack.enter_context(frobulate(cheese))
# do stuff with spam, eggs, cheese
I prefer the first, even with the long line.
I agree with Steven for *small* numbers of context managers. Once they
become too long though, either refactoring is severely needed or the
user should ExitStack.
To quote Ben Hoyt:
Is it meaningful to use with with a tuple, though? Because a tuple
isn't a context manager with __enter__ and __exit__ methods. For
example:
with (1,2,3): pass
...
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: __exit__
So -- although I'm not arguing for it here -- you'd be turning an code
(a runtime AttributeError) into valid syntax.
I think by introducing parentheses we are going to risk seriously
confusing users who may then try to write an assignment like
a = (open('spam') as spam, open('eggs') as eggs)
Because it looks like a tuple but isn't and I think the extra
complexity this would add to the language would not be worth the
benefit. If we simply look at Ruby for what happens when you have an
overloaded syntax that means two different things, you can see why I'm
against modifying this syntax. In Ruby, parentheses for method calls
are optional and curly braces (i.e, {}) are used for blocks and hash
literals. With a method on class that takes a parameter and a block,
you get some confusing errors, take for example:
class Spam
def eggs(ham)
puts ham
yield if block_present?
end
end
s = Spam.new
s.eggs {monty: 'python'}
SyntaxError: ...
But
s.eggs({monty: 'python'})
Will print out the hash. The interpreter isn't intelligent enough to
know if you're attempting to pass a hash as a parameter or a block to
be executed. This may seem like a stretch to apply to Python, but the
concept of muddling the meaning of something already very well defined
seems like a bad idea.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]
Stefan, If the only way you can think of to invalidate Donald's (vastly superior) arguments is to accuse of him of gossip, you should probably reconsider your arguments. Looking at the conversation you didn't actually link to (https://botbot.me/freenode/python-requests/msg/14389415/) there is no gossip. There are no insinuations about your character. All that is there is a succinct description of the topic of this conversation. Cheers, Ian On Fri, May 9, 2014 at 11:23 AM, Donald Stufft don...@stufft.io wrote: On May 9, 2014, at 12:11 PM, Stefan Krah ste...@bytereef.org wrote: Donald, I'm out of his discussion. I have one last request: please don't gossip about core devs in public as long as you have commit privs: https://botbot.me/freenode/python-requests/ I don’t really know how to respond to this. I was talking to some people I know and I gave them a summary of what was happening. I stand by everything I said there and I don’t think any of it was wrong or even gossip at all. If people feel that was inappropriate then go ahead and take my commit privs. I have them to make it easier for me to write PEPs and to update ensurepip. If they’re going to be used as an excuse to attempt to censor me then I’d rather not have them as I generally always speak my mind and I won’t stop doing so. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pip SSL
Also the three of us maintaining requests and the author of urllib3 are all very conscious that the packaged pem file is outdated. We have an open issue about how to rebuild it accurately while taking into consideration (and not including) the ones that have been revoked. Any suggestions you have can be sent to me off list or reported on the issue tracker. On Sat, Oct 19, 2013 at 12:57 PM, Donald Stufft don...@stufft.io wrote: One of the reasons we switched to using requests was to help centralize the SSL handling code over to requests. So any issues could be fixed there and we just pull in a newer version of requests. On Oct 19, 2013, at 11:52 AM, Christian Heimes christ...@python.org wrote: Signed PGP part Am 19.10.2013 16:59, schrieb Nick Coghlan: It's the cert verification in pip that's relevant - the PEP was updated so that ensurepip itself never talks to the internet. So I guess that would mean checking the cert verification in pip's vendored copy of requests: https://github.com/pypa/pip/tree/develop/pip/vendor/requests (So I guess if you do find any issues, they would likely be applicable to the upstream requests package as well) Oh heck, where should I start? The cacert.pem file is outdated. Also it's unclear who has generated the file and how it was generated from certdata.txt. It may very well contain revoked certificates, too. You can find the latest version of the file at http://hg.mozilla.org/mozilla-central/file/tip/security/nss/lib/ckfw/builtins/certdata.txt . A proper tool is required to generate a correct PEM file. It must understand *ALL* fields. I have some code for that but it's not ready yet. pip uses requests and requests rolls its own code for or on top of Python stdlib modules, e.g. urllib3 with ssl_match_hostname. The method has the same security flaw as Python's ssl.match_hostname() function for IDNs. I'm a bit worried that we have to review and validate all 3rd party packages and copies of stdlib modules for issues. The assert_fingerprint() function looks kinda funny. It uses sha1() or md5() on the DER representation of the cert. It's not how you are suppose to take fingerprints for cert pinning. But Python's ssl has no way to get the SPKI from the cert yet. I'm working on that as well. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I cannot create bug reports
The first thing that comes to mind is that your session expired and you need to log-in again. After logging in myself I see the form in all of it's glory. On Wed, Apr 24, 2013 at 2:35 PM, Daniel Wong allyourc...@gmail.com wrote: Glorious members of python-dev, I'd like to submit a patch, but I cannot create a bug report. As of this morning (US West Coast), when I go to http://bugs.python.org/issue?@template=item I get no form fields. I went there last night, and I was able to get a form. I kept that tab open over night, and tried to submit this morning. When I did that, I got permission denied errors. It seems that something weird has happened to my account, or bug tracker itself changed in my sleep. Anyone have any idea what's going on here? Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Announcement] New mailing list for code quality tools including Flake8, Pyflakes and Pep8
On Wed, Apr 3, 2013 at 9:21 PM, Alfredo Solano Martínez asol...@icai.es wrote: Hi, Are you planning to cover the code quality of the interpreter itself too? I've been recently reading through the cert.org secure coding practice recommendations and was wondering if there has is any ongoing effort to perform static analysis on the cpython codebase. Hey Alfredo, We do not currently have any tools to do that, but it would definitely be something interesting to discuss and maybe design on the list. I'm sure there are static analysis tools for the C part and I'm sure we as a community could come up with a super tool to check both the C and Python parts of CPython. -- Ian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [Announcement] New mailing list for code quality tools including Flake8, Pyflakes and Pep8
Hello, There's a new mailing-list related to Python code-quality tools. Are you concerned about the evolution of various code checkers? Do you have questions or suggestions? Subscribe here: http://mail.python.org/mailman/listinfo/code-quality Best regards, Ian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can't upload to PyPI
This is probably better suited to Catalog-sig but you have to edit your credentials in $HOME/.pypirc On Thu, Feb 21, 2013 at 9:02 PM, MRAB pyt...@mrabarnett.plus.com wrote: Since the PyPI security notice of 2013-02-15 I've been unable to upload to PyPI via setup.py upload. I changed my password during the grace period, and have reset it, but it's still rejected: Upload failed (401): Incorrect password I can login to PyPI with the password. Can anyone suggest what could be wrong? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/graffatcolmingov%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can't upload to PyPI
On Thu, Feb 21, 2013 at 9:27 PM, MRAB pyt...@mrabarnett.plus.com wrote: On 2013-02-22 02:09, Ian Cordasco wrote: On Thu, Feb 21, 2013 at 9:02 PM, MRAB pyt...@mrabarnett.plus.com wrote: Since the PyPI security notice of 2013-02-15 I've been unable to upload to PyPI via setup.py upload. I changed my password during the grace period, and have reset it, but it's still rejected: Upload failed (401): Incorrect password I can login to PyPI with the password. Can anyone suggest what could be wrong? This is probably better suited to Catalog-sig but you have to edit your credentials in $HOME/.pypirc Are any other changes needed in .pypirc, _apart_ from the password? I don't recall needing any other changes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why do we allow this syntax?
On Feb 8, 2013 3:37 PM, Xavier Morel catch-...@masklinn.net wrote:
On 2013-02-08, at 18:45 , Chris Withers wrote:
On 08/02/2013 16:17, Oscar Benjamin wrote:
Decimal.__pos__ uses it to return a Decimal instance that has the
default precision of the current Decimal context:
from decimal import Decimal
d = Decimal('0.33')
d
Decimal('0.33')
+d
Decimal('0.')
That's the answer I was hoping wouldn't be coming...
Oh well, guess I'll have to improve on my sloppy typing.
Or just run flake8 (with a bit of configuration to disable the annoying
stuff).
As flake8's maintainer, I second this.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
