Why does HG cpython repo contains .{bzr,git}ignore at all?
IMHO, all .*ignore files should be strictly repository dependent and
they should not be mixed together.
It is even worse, that (understandingly) .{bzr,git}ignore are apparently
poorly maintained, so in order to get an equivalent of
On 1.4.2012 23:46, Brian Curtin wrote:
For what reason? Are the git or bzr files causing issues on HG?
No, but wrong .gitignore causes issues with git repo obtained via
hg-fast-import. If it is meant as an intentional sabotage of using git
(and bzr) for cpython, then that's the only
On 2.4.2012 00:52, Guido van Rossum wrote:
Please file a bug to get this reviewed and checked in.
OK, I don't agree with the reasoning, but I willingly submit to BDFL ;)
http://bugs.python.org/issue14472
Matěj
___
Python-Dev mailing list
Hi,
GitHub API v3 is intentionally broken (see
http://developer.github.com/v3/auth/):
The main difference is that the RFC requires unauthenticated requests
to be answered with 401 Unauthorized responses. In many places, this
would disclose the existence of user data. Instead, the GitHub API
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-01-10, 12:19 GMT, you wrote:
Using the 'latin-1' to mean unknown encoding can easily result
in Mojibake (unreadable text) entering your application with
dangerous effects on your other text data.
E.g. Marc-André read using 'latin-1' if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-01-10, 17:34 GMT, you wrote:
From my experience, the concept of a default locale is deeply
flawed. What if I log into a (Linux) machine using an old
latin-1 putty from the Windows XP era, have most file names
and contents in UTF-8
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-01-11, 10:56 GMT, you wrote:
I don't know what the fuss is about.
I just cannot resist:
When you are calm while everybody else is in the state of
panic, you haven’t understood the problem.
-- one of many collections of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-01-11, 18:09 GMT, you wrote:
We are NOT going back to the confusing incoherent mess that
is the Python 2 model of bolting Unicode onto the side of
POSIX . . .
We are not asking for that.
Yes, you do. Maybe not you personally, but
to contribute to Python itself, so please be
gentle with me. Yes, I know that I miss unit tests and port to other
branches of Python (this is against 2.7), but I would like first some
feedback to see what I am missing (aside from the mentioned).
Matěj Cepl
---
Lib/urllib2.py | 35
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2014-02-11, 12:27 GMT, you wrote:
This is my first attempt to contribute to Python itself, so
please be gentle with me. Yes, I know that I miss unit tests
and port to other branches of Python (this is against 2.7),
but I would like first
On 2013-02-26, 16:25 GMT, Terry Reedy wrote:
On 2/21/2013 4:22 PM, Matej Cepl wrote:
as my method to commemorate Aaron Swartz, I have decided to port his
html2text to work fully with the latest python 3.3. After some time
dealing with various bugs, I have now in my repo
Hi,
now when the vacations even in Europe are over could I ask for
some movement on http://bugs.python.org/issue19494? Demanding
a half-megabyte amount of packages from PIP ('just use requests'
mentioned by some comments in the thread) or for that matter any
package from PIP (including mine
On 2014-09-25, 23:14 GMT, Cameron Simpson wrote:
Fortunately, Python's subprocess has its `shell` argument default to
False. However, `os.system` invokes the shell implicitly and is
therefore a possible attack vector.
Only if /bin/sh is bash :-) Not always the case, fortunately.
Where does your
On 2014-10-06, 20:03 GMT, Victor Stinner wrote:
I started a list of Python 2 bugs that will not be fixed:
http://haypo-notes.readthedocs.org/python.html\
#bugs-that-won-t-be-fixed-in-python-2-anymore
It *is* possible to fix all bugs, but it requires a large amount of
work, and we decided to
On 2014-11-30, 11:18 GMT, Ben Finney wrote:
Donald Stufft don...@stufft.io writes:
I think there is a big difference here between using a closed source
VCS or compiler and using a closed source code host. Namely in that
the protocol is defined by git so switching from one host to another
is
On 2014-12-01, 02:12 GMT, Pierre-Yves David wrote:
Migrating the DVCS content is usually easy.
This is lovely mantra, but do you speak from your own
experience? I did move rope from Bitbucket to
https://github.com/python-rope and it was A LOT of work
(particularly issues, existing pull
On 2014-12-01, 00:50 GMT, Donald Stufft wrote:
The only thing that is true is that git users are more likely to use the
ability to rewrite history than Mercurial users are, but you’ll typically
find that people generally don’t do this on public branches, only on private
branches.
And I would
On 2014-12-01, 07:43 GMT, Donald Stufft wrote:
I do not choose tools simply because they are written in
Python -- I choose them because, being written in Python, I
I can work on them if I need to: I can enhance them, I can
fix them, I can learn from them.
Git uses the idea of small
On 2014-12-11, 14:47 GMT, Giampaolo Rodola' wrote:
I still think the only *real* obstacle remains the lack of
important packages such as twisted, gevent and pika which
haven't been ported yet.
And unwise decisions of some vendors (like, unfortunately my
belvoed employer with RHEL-7) not to
On 2016-12-16, 23:59 GMT, Guido van Rossum wrote:
> No need to get all bent out of shape. My proposal is to simply
> add a note to the docs recommending against using this.
> I wouldn't change any code, not even a silent deprecation
> warning. (Also, read the rest of the thread to learn why
On 2016-12-16, 19:24 GMT, Guido van Rossum wrote:
> I am beginning to think that `from __future__ import unicode_literals` does
> more harm than good. I don't recall exactly why we introduced it, but with
> the restoration of u"" literals in Python 3.3 we have a much better story
> for writing
On 2018-04-28, 01:23 GMT, Nick Coghlan wrote:
> That isn't currently *my* desired future, as I don't want to
> see a python3 to python4 naming transition at any point,
> I want a transition from python3 back to an unqualified name
> to accurately reflect the change in version management
>
On 2018-04-28, 01:33 GMT, Greg Ewing wrote:
>> In my opinion, the largest failure of Python 3 is that we
>> failed to provide a smooth and *slow* transition from Python
>> 2 and Python 3.
>
> Although for some things, such as handling of non-ascii text, it's
> hard to see how a smooth transition
On 2018-06-05, 15:03 GMT, Nick Coghlan wrote:
> I was actually looking into this recently to see if the
> repository import feature could be used to run a regularly
> updated repository mirror that included all issues and PR
> comments in addition to the code,
Good, thank you very much. I
On 2018-06-04, 16:06 GMT, Guido van Rossum wrote:
> I don't see how this *increases* the uncertainty. Surely if
> GitHub had remained independent there would have been be
> similar concerns about how it would make enough money to stay
> in business.
Beacuse Microsoft is known to keep a money
On 2018-06-04, 23:38 GMT, Steven D'Aprano wrote:
> No, but Guido is right: neither is anyone else.
>
> In that regard, Microsoft is probably *more* likely to keep pumping
> money into a failing business if it gives them a strategic advantage,
> compared to other investors with no long-term
On Mon, 2018-07-02 at 14:13 +0200, Victor Stinner wrote:
> 2018-07-02 9:38 GMT+02:00 Petr Viktorin :
> > Fedora* has been building python37 since the alphas, so the
> > final update to
> > rc/stable was smoother.
> > (...)
> > * Thanks to Miro Hrončok for most of the work in Fedora
>
> This work
On 2018-06-28, 00:58 GMT, Ned Deily wrote:
> On behalf of the Python development community and the Python 3.7 release
> team, we are pleased to announce the availability of Python 3.7.0.
I am working on updating openSUSE packages to python 3.7, but
I have hit quite large number of failing tests
On 2018-05-02, 21:41 GMT, Guido van Rossum wrote:
> So what do *you* think. Do you agree with the OP that Tkinter (and hence
> IDLE) should be scrapped?
It absolutely impossible to remove Tkinter IMHO (it has been
part of stdlib since like forever and people expect it there;
its removal would
, and I'm so old & out-of-it that I'm +1 on
> the binding expressions PEP ;-)
Glad to find that such person exists! I thought that you are
just a mythical legend, I am glad to be shown otherwise.
Best,
Matěj Cepl
--
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3
On 2018-02-21, 21:49 GMT, Chris Angelico wrote:
> Said PEP may also need to mention the possibility of exporting
> the history of GitHub issues, in case CPython ever migrates away from
> GitHub; I remember that concern being raised when the original
> migration was discussed.
There are tools for
On 2018-08-08, 11:30 GMT, Antoine Pitrou wrote:
> I'm not sure why anyone would want to use swig nowadays.
Legacy reasons, 47k lines of Python code (and 7k lines of swig
*.i files).
Matěj
--
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D
On 2018-08-06, 15:13 GMT, Stefan Behnel wrote:
> Not sure I understand this correctly, but I think we're on the
> same page here: writing test code in C is cumbersome, writing
> test code in a mix of C and Python across different files is
> aweful. And making it difficult to write or even just
On 2018-08-07, 17:34 GMT, Yury Selivanov wrote:
> Speaking of which, Dropbox is working on a new compiler they
> call "mypyc".
How does it compare with Nuitka?
Matěj
--
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
If
On 2018-07-07, 15:48 GMT, Guido van Rossum wrote:
> if validate(name := re.search(pattern, line).group(1)):
> return name
Except there is no error handling for situations when
re.search() returns None, so one shouldn't use it anyway (most
of the time). Which seems to me like another
On 2018-07-08, 22:32 GMT, Larry Hastings wrote:
> More importantly, 3.4 is in security-fixes-only mode, which
> means that changes that aren't security fixes won't be
> accepted.
So, why isn’t https://bugs.python.org/issue31623 closed as
WONTFIX (or whatever is the equivalent in b.p.o)? If we
On Wed, 2018-07-04 at 22:05 +1000, Nick Coghlan wrote:
> Running the following locally fails for me:
>
> $ SOURCE_DATE_EPOCH=`date` ./python -m test test_py_compile
> test_compileall
Just if this is taken literally, it is wrong. According to https:
On 2018-03-12, 13:13 GMT, Nick Coghlan wrote:
> +1 from me, as even if commercial redistributors do decide
> they want to collaborate on a post-2020 Python 2.7 maintenance
> branch, there's no technical reason that that needs to live
> under the "python" GitHub organisation, and some solid
>
On 2018-03-11, 03:45 GMT, Terry Reedy wrote:
> When processed properly, a day to a week, usually, a * will
> appear after your name on any tracker (bpo) post.
So, I got my start after the name, where is the list of
maintainers of individual packages, so I could know whom to
bother to take a
On 2018-04-07, 00:13 GMT, Steven D'Aprano wrote:
> Just in the last week, I've been reminded twice that many
> people using Python do so where they cannot just arbitarily
> pip install , and if a library isn't in the std lib,
> they can't use it without a lot of pain:
100% agree + one of the
On 2018-04-21, 07:46 GMT, Chris Angelico wrote:
> doubled_items = [x for x in (items := get_items()) if x * 2 in
> items]
Aside from other concerns expressed elsewhere by other people,
do you really like this? I know and agree that “readability” is
a subjective term, but it is my firm
On 2018-04-23, 21:34 GMT, Sven R. Kunze wrote:
> Is it just me or since when has the following Python code
> fallen out of favor?
It isn’t just you.
Matěj
--
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
… one of the
On 2018-03-03, 02:15 GMT, Elias Zamaria wrote:
> It seems like I can either subscribe and get emails for all of
> the threads, or unsubscribe and not get any emails, making me
> unable to reply to the threads I want to reply to.
Go to https://mail.python.org/mailman/listinfo/python-dev in the
On 2018-11-21, 14:54 GMT, Benjamin Peterson wrote:
> In Python 3, there is no underlying FILE* because the io
> module is implemented using fds directly rather than C stdio.
OK, so the proper solution is to kill all functions which expect
FILE, and if you are anal retentive about stability of
On 2018-11-19, 11:59 GMT, Stefan Krah wrote:
> In practice people desperately *have* to use whatever is
> there, including functions with underscores that are not even
> officially in the C-API.
Yes, there are some functions which evaporated and I have never
heard a reason why and how I am
On 2018-11-22, 10:13 GMT, Petr Viktorin wrote:
> Yes, AFAIK that is the least bad solution.
> I did something very similar here:
> https://github.com/encukou/py3c/blob/master/include/py3c/fileshim.h
Thank you.
Matěj
___
Python-Dev mailing list
On 2019-02-13, 23:33 GMT, Barry Warsaw wrote:
> Perhaps. I just don’t think Python 4 is anything but distant
> vaporware. There’s a cost to freaking everyone out that
> Python 4 is coming and will be as disruptive as Python 3.
> Calling Python 3.9+1 Python 4 feeds into that FUD for no
>
On 2019-05-01, 06:46 GMT, Serhiy Storchaka wrote:
> These lines were added for purpose. They are needed for
> running tests in separate file as a script.
>
> $ ./python Lib/unittest/test/testmock/testcallable.py -v
> test_attributes (__main__.TestCallable) ... ok
Isn't the standard way how to
On 2020-02-04, 01:00 GMT, Brett Cannon wrote:
> I think people also forget that prior to worrying about
> maintaining backwards-compatibility with Python 2 we
> deprecated for a release and then we removed (so an 18 month
> deprecation period).
But then you mustn’t filter out deprecation
On 2020-04-13, 17:39 GMT, Eric Fahlgren wrote:
> Ok, so put that in a Pros/Cons list that provides guidance as to what
> interface and tools to choose when writing a new extension module.
> Personally, I'd put Cython (and other "big" packages, numpy, requests and
> such) on par with CPython itself
On 2020-04-14, 12:35 GMT, Stefan Behnel wrote:
>> A good way to test that promise (or other implications like performance)
>> might
>> also be to rewrite the standard library extensions in Cython and see where
>> it
>> leads.
>
> Not sure I understand what you're saying here. stdlib extension
51 matches
Mail list logo
