Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On Tue, May 12, 2015 at 4:36 PM, Larry Hastings wrote: > BTW, this workload was exacerbated by my foolish desire to keep the revision > DAG nice and clean. So I was actually starting over from scratch and > redoing all the cherry-picking every couple of days, just so I could get all > the cherry-picked revisions in strict chronological order. By the end I had > evolved a pretty elaborate guided-process automation script to do all the > cherry-picking, which you can see here if you're curious: Couldn't you just keep this as a branch that you then keep rebasing (without unlinking the original branch)? It doesn't seem like something that needs a one-off script, to me. Cheers, Dirkjan ___ 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] Add Gentoo packagers of external modules to Misc/ACKS
Tae Wong, Please don't speak on behalf the Gentoo Python team. Everyone else, sorry for this, they are definitely not actually connected to our Gentoo team. Cheers, Dirkjan ___ 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 startup time
On Thu, Oct 10, 2013 at 2:25 PM, Christian Heimes wrote: > Benchmark of 1000 times "python -c ''" > > Python 3.4dev with all my experimental patches: > > Avg: 0.705161 -> 0.443613: 1.59x faster > > 2.7 -> 3.4dev: > > Avg: 0.316177 -> 0.669330: 2.12x slower > > 2.7 -> 3.4dev with all my patches: > > Avg: 0.314879 -> 0.449556: 1.43x slower > > http://pastebin.com/NFrpa7Jh > > Ain't bad! The benchmarks were conducted on a fast 8 core machine with SSD. This seems promising. What OS are you using? On an older Linux server with old-style HD's, the difference between 2.7 and 3.2 is much larger for me: Avg: 0.0312 -> 0.1422: 4.56x slower (In this case, I think it might be more useful to report as 0.11s faster, though.) Cheers, Dirkjan ___ 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-431 non-status
On Wed, Oct 2, 2013 at 2:17 PM, Lennart Regebro wrote: > If you wonder about the lack of progress reports on pep-431, this is > because of a lack of progress. I simply haven't had any time to work > on this. I considered make a kickstarter so I could take time off from > working, but to be honest, even with that, I still have no time to > realistically get this in before beta 1. Is there a list of stuff that needs to be done? I might be able to help out. Cheers, Dirkjan ___ 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] Add a "transformdict" to collections
On Tue, Sep 10, 2013 at 11:28 AM, Antoine Pitrou wrote: > On the tracker issue, it seems everyone agreed on the principle. There > is some bikeshedding left to do, though. So here are the reasonable > naming proposals so far: > > - transformkeydict > - coercekeydict > - transformdict > - coercedict > > I have a sweet spot for "transformdict" myself. Given OrderedDict, it seems like this should definitely be TransformDict rather than transformdict. Cheers, Dirkjan ___ 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] Offtopic: OpenID Providers
On Thu, Sep 5, 2013 at 10:33 PM, Glenn Linderman wrote: > Is there a Python implementation of Persona I can install on my web server? If you mean to use your web server as an Identity Provider, try this: https://bitbucket.org/djc/persona-totp It currently only implements TOTP-based authentication (i.e. no passwords), but it should be easy to add a password or 2FA-mode if you'd prefer that. Cheers, Dirkjan ___ 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] Offtopic: OpenID Providers
On Thu, Sep 5, 2013 at 10:57 PM, Donald Stufft wrote: > Not that it changes this statement at all but you wouldn't expect to see a > Persona login > for gmail as persona solves the problem that people don't think of urls as > personal > identifiers by replacing it with emails. So Gmail would be the Persona IdP And actually you can already trivially login with your GMail account on any Persona-based Relying Party (that is, a site that uses Persona to authenticate you). This is because one of the nice parts of the current implementation of Persona is that Mozilla has implemented bridges that allow GMail and Yahoo addresses to be authenticated via their respective OAuth implementations, such that you don't need to setup an account at Mozilla's fallback IdP (which acts as an Identity Provider for email addresses that don't currently have an IdP available to them). Cheers, Dirkjan ___ 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] Offtopic: OpenID Providers
On Thu, Sep 5, 2013 at 10:30 PM, Tres Seaver wrote: > +1 for supporting Persona as an alternative to OpenID on all *.python.org > servers. BTW, I'd be happy to assist with any Persona RP implementations for python.org services. The MDN docs are pretty good, I got my first RP going in just a few hours of looking at code (and you can probably do better if you're more into frontend webdev stuff). There's also ongoing work that will replace ReadTheDocs accounts with Persona support. Cheers, Dirkjan ___ 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] Official github mirror for CPython?
On Fri, Jul 26, 2013 at 9:50 AM, Antoine Pitrou wrote: >> (For those that haven't seen it, RhodeCode seems broadly comparable to >> BitBucket feature wise, but because of the way it is licensed, the >> source code is freely available to all, and running your own instance >> is free-as-in-beer for non-profits and open source projects). > > By "freely available", do you mean actual open source / free software? It seems to be licensed under the GPLv3. https://secure.rhodecode.org/rhodecode/files/433d6385b216da52f68fa871ed1ff99f8d618613/COPYING https://rhodecode.com/blog/25/new-rhodecode-licensing Cheers, Dirkjan ___ 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] Python 3 as a Default in Linux Distros
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote:
> - What should user get after using "yum install python"?
> There are basically few ways of coping with this:
> 1) Just keep doing what we do, eventually far in the future drop "python"
> package and never provide it again (= go on only with python3/python4/...
> while having "yum install python" do nothing).
> 2) Do what is in 1), but when "python" is dropped, use virtual provide (*)
> "python" for python3 package, so that "yum install python" installs python3.
> 3), 4) Rename python to python2 and {don't add, add} virtual provide "python"
> in the same way that is in 1), 2)
> 5) Rename python to python2 and python3 to python at one point. This makes
> sense to me from the traditional "one version in distro + possibly compat
> package shipping the old" approach in Linux, but some say that Python 2 and
> Python 3 are just different languages [3] and this should never be done.
> All of the approaches have their pros and cons, but generally it is all about
> what user should get when he tries to install python - either nothing or
> python2 for now and python3 in future - and how we as a distro cope with that
> on the technical side (and when we should actually do the switch).
> Just as a sidenote, IMO the package that gets installed as "python" (if any)
> should point to /usr/bin/python, which makes consider these two points very
> closely coupled.
On Gentoo we get python2 and python3 executables and have user-level
tools to change what the 'python' symlink points to. I think we
default to only having Python 3 installed (and Python 3 is even made
the default Python), though it's currently always the case that Python
2 gets pulled in by some core dependencies.
Cheers,
Dirkjan
___
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] Bilingual scripts
On Fri, May 24, 2013 at 10:23 PM, R. David Murray wrote:
> Gentoo has a (fairly complex) driver script that is symlinked to all
> of these bin scripts. The system then has the concept of the
> "current python", which can be set to python2 or python3. The default
> bin then calls the current default interpreter. There are also
> xxx2 and xxx3 versions of each bin script, which call the 'current'
> version of python2 or python3, respectively.
I'm one of the Gentoo devs, on the python team. I haven't actually
written any code for this, but I can show a little of what's going on.
I think most of the code is actually in
https://bitbucket.org/mgorny/python-exec. We then install three
scripts:
lrwxrwxrwx 1 root root 11 May 20 14:06 /usr/bin/sphinx-build -> python-exec
-rwxr-xr-x 1 root root 311 May 20 14:06 /usr/bin/sphinx-build-python2.7
-rwxr-xr-x 1 root root 311 May 20 14:06 /usr/bin/sphinx-build-python3.2
sphinx-build-python2.7 looks like this:
#!/usr/bin/python2.7
# EASY-INSTALL-ENTRY-SCRIPT: 'Sphinx==1.1.3','console_scripts','sphinx-build'
__requires__ = 'Sphinx==1.1.3'
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.exit(
load_entry_point('Sphinx==1.1.3', 'console_scripts', 'sphinx-build')()
)
We now use a python2.7 suffix rather than just a 2.7 suffix because we
will install separate wrappers for e.g. pypy1.9 (and we are also
prepared to support jython or other implementations at some point).
If you have any more questions, I'll try to answer them; or, join
#gentoo-python on Freenode, there are generally people hanging out
there who know much more about our setup than I do.
Cheers,
Dirkjan
___
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] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info
On Tue, May 14, 2013 at 12:14 PM, Ben Hoyt wrote: > I don't think that's a big issue, however. If it's 3-8x faster in the > majority of cases (local disk on all systems, Windows networking), and > no slower in a minority (sshfs), I'm not too sad about that. Might be interesting to test something status calls with a hacked Mercurial. Cheers, Dirkjan ___ 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] libffi inclusion in python
On Thu, Apr 18, 2013 at 11:17 PM, Ronald Oussoren wrote: > Stripping libffi from python's source tree would be fine by me, but would > require testing with upstream libffi. AFAIK system libffi on osx wouldn't be > goog enough, it doesn't work properly with clang. If you mean http://bugs.python.org/issue17136, I think that has been fixed in libffi upstream? Cheers, Dirkjan ___ 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] PEP 435 -- Adding an Enum type to the Python standard library
On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky wrote: > Ordered comparisons between enumeration values are *not* supported. Enums > are > not integers (but see `IntEnum`_ below):: > > >>> Colors.red < Colors.blue > Traceback (most recent call last): > ... > NotImplementedError > >>> Colors.red <= Colors.blue > Traceback (most recent call last): > ... > NotImplementedError > >>> Colors.blue > Colors.green > Traceback (most recent call last): > ... > NotImplementedError > >>> Colors.blue >= Colors.green > Traceback (most recent call last): > ... > NotImplementedError I like much of this PEP, but the exception type for this case seems odd to me. Wouldn't a TypeError be more appropriate here? Somewhat like this: >>> 'a' - 'b' Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for -: 'str' and 'str' Cheers, Dirkjan ___ 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] casefolding in pathlib (PEP 428)
On Thu, Apr 11, 2013 at 11:27 PM, Antoine Pitrou wrote: > Hmm, I think I'm tending towards the latter right now. You might also want to look at what Mercurial does. As a cross-platform filesystem-oriented tool, it has some interesting issues in the department of casefolding. Cheers, Dirkjan ___ 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] cffi in stdlib
On Tue, Feb 26, 2013 at 4:13 PM, Maciej Fijalkowski wrote: > I would like to discuss on the language summit a potential inclusion > of cffi[1] into stdlib. This is a project Armin Rigo has been working > for a while, with some input from other developers. It seems that the > main reason why people would prefer ctypes over cffi these days is > "because it's included in stdlib", which is not generally the reason I > would like to hear. Our calls to not use C extensions and to use an > FFI instead has seen very limited success with ctypes and quite a lot > more since cffi got released. The API is fairly stable right now with > minor changes going in and it'll definitely stablize until Python 3.4 > release. I think this would be great to have in the stdlib. I think it's useful to note that PyPy is planning to include this in their stdlib for the next release, too, right? Cheers, Dirkjan ___ 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] PEP 431 Time zone support improvements - Update
On Mon, Jan 7, 2013 at 5:57 PM, Lennart Regebro wrote: > Will this help the makers of distributions, like Ubuntu etc? If that is the > case, then it might be worth doing, otherwise I don't think it's very > useful. As a Gentoo packager, I think it's useful. Cheers, Dirkjan ___ 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] PEPs in progress
On Wed, Jan 2, 2013 at 7:14 AM, Christian Heimes wrote: > The second PEP addresses key derivation functions for secure password > hashing. I like to add PBKDF2, bcrypt and scrypt facilities to the > standard library. Hashing only? I was hoping you would also include PKCS1 RSA primitives. Cheers, Dirkjan ___ 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] PEP 431 Time zone support improvements - Update
On Sat, Dec 29, 2012 at 11:45 AM, Antoine Pitrou wrote: >> I'm still a fan of *always* shipping fallback tzdata, regardless of >> platform. The stdlib would then look in three places for timezone data >> when datetime.timezone was first imported: >> >> 1. the "tzdata-update" database >> 2. the OS provided database >> 3. the fallback database > > +1 ! Yeah, from me as well. Cheers, Dirkjan ___ 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] Draft PEP for time zone support.
On Wed, Dec 12, 2012 at 4:56 PM, Lennart Regebro wrote: >> Why not keep a bit more of the pytz API to make porting easy? > > The renaming of the timezone() function to get_timezone() is indeed small, > but changing pytz.timezone(foo) to timezone.timezone(foo) is really > significantly easier than renaming it to timezone.get_timezone(foo). > > If we keep all of the API intact you could do > > try: > import pytz as timezone > except ImportError: > import timezone > > Which would make porting quicker, that's true, but do we really want to keep > unecessary API's around forever? Isn't it better to minimize the noise from > the start? That entirely depends on when you define to be "the start". It seems to me the consensus on python-dev has been that packages primarily evolve outside the stdlib; it seems a bit weird to then, at the time of stdlib inclusion, start changing the API. >> Why is it True by default? Do we have statistics showing that Python >> gets more use in summer? > > Because for some reason both me and Stuart Bishop thought it should be, but > at least in my case I don't have any actual good reason why. Checking with > how pytz does this shows that pytz in fact defaults to False, so I think > the default should be False. Here, too, I think that sticking with pytz's default would be a good idea. Cheers, Dirkjan ___ 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] Draft PEP for time zone support.
On Tue, Dec 11, 2012 at 4:23 PM, Lennart Regebro wrote: > Proposal > > > The time zone support will be implemented by a new module called `timezone``, > based on Stuart Bishop's ``pytz`` module. I wonder if there needs to be something here about how to port from pytz to the new timezone library. > * New function :``get_timezone(name=None, db=None)`` > > This function takes a name string that must be a string specifying a > valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or "Etc/GMT+11". > If not given, the local timezone will be looked up. If an invalid zone name > are given, or the local timezone can not be retrieved, the function raises > `UnknownTimeZoneError`. > > The function also takes an optional path to the location of the zoneinfo > database which should be used. If not specified, the function will check if > the `timezonedata` module is installed, and then use that location > or otherwise > use the database in ``/usr/share/zoneinfo``. > > If no database is found an ``UnknownTimeZoneError`` or subclass thereof will > be raised with a message explaining that no zoneinfo database can be found, > but that you can install one with the ``timezonedata`` package. It seems like calling get_timezone() with an unknown timezone should just throw ValueError, not necessarily some custom Exception? It would probably be a good idea to have a different exception for the case of no database available. > Differences from the ``pytz`` API > = > > * ``pytz`` has the functions ``localize()`` and ``normalize()`` to work > around that ``tzinfo`` doesn't have is_dst. When ``is_dst`` is > implemented directly in ``datetime.tzinfo`` they are no longer needed. > > * The ``pytz`` method ``timezone()`` is instead called > ``get_timezone()`` for clarity. > > * ``get_timezone()`` will return the local time zone if called > without parameters. > > * The class ``pytz.StaticTzInfo`` is there to provide the ``is_dst`` > support for static > timezones. When ``is_dst`` support is included in > ``datetime.tzinfo`` it is no longer needed. This feels a bit superfluous. Why not keep a bit more of the pytz API to make porting easy? The pytz API has proven itself in the wild, so I don't see much point in renaming "for clarity". It also seems relatively painless to keep localize() and normalize() functions around for easy porting. > Discussion > == > > Should the windows installer include the data package? > -- > > It has been suggested that the Windows installer should include the data > package. This would mean that an explicit installation no longer would be > needed on Windows. On the other hand, that would mean that many using Windows > would not be aware that the database quickly becomes outdated and would not > keep it updated. I still submit that it's pretty much just as easy to forget to update the database whether it's been installed by hand zero or one times, so I don't find your argument convincing. I don't mind the result much, though. Looking forward to have timezone support in the stdlib! Cheers, Dirkjan ___ 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] [Distutils] [Catalog-sig] accept the wheel PEPs 425, 426, 427
On Tue, Nov 13, 2012 at 4:00 PM, Daniel Holth wrote: > I'm willing to go ahead and move any mention of signing algorithms into a > separate PEP, leaving only the basic manifest hash vs. file contents > verification under the auspices of this PEP. >From the discussion so far, that seems like the smart thing to do. Cheers, Dirkjan ___ 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] PEP 427 comment: code signing
On Tue, Oct 23, 2012 at 7:46 AM, wrote:
> That's exactly what I want: it (PEP 427) should use one of the algorithms
> that is built-in (into web signatures). Web signatures give a choice of
> three algorithms; yet Daniel proposes to deviate and use a non-builtin
> algorithm.
>
> None of the algorithms in question are built in in Python; the two
> standard algorithms with public keys (i.e. RSA and ECDSA) are both
> built into OpenSSL.
What leads you to say that? ISTM Python has perfectly good support for
JWS/JWA's HS256 algorithm. In fact, here's an implementation that I
think would conform to the current JWS draft:
def sign(payload, key):
h = json.dumps({'alg': 'HS256'})
input = b64uencode(h) + '.' + b64uencode(json.dumps(payload))
sig = hmac.new(key, input, hashlib.sha256).digest()
return input + '.' + b64uencode(sig)
(b64u implementations elided; see
https://bitbucket.org/djc/persona-totp for the rest of the code.)
Cheers,
Dirkjan
___
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] Proposed schedule for Python 3.4
On Thu, Oct 4, 2012 at 12:32 PM, Christian Heimes wrote: > Two days ago NIST announced the SHA-3 contest winner. My wrapper of > keccak https://bitbucket.org/tiran/pykeccak/ is almost ready and just > needs some cleanup and more tests. Once it's done I'll remove the Python > 3.2 and 2.x compatibility code and integrate it into 3.4. See also https://github.com/bjornedstrom/python-sha3. Cheers, Dirkjan ___ 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] Stdlib and timezones, again
On Mon, Oct 1, 2012 at 3:22 PM, Nick Coghlan wrote: > Since explicit is better than implicit, I *wouldn't* want to see > magical side affects where merely installing the database from PyPI, > or switching from Windows to Linux caused different behaviour. I think that would be a pain. What you're proposing means that Linux installations have to use the Python-installed copy by default (because you want them to do the same thing as on Windows), even though they have a perfectly good copy, often newer, of the database installed on the system. Cheers, Dirkjan ___ 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] Stdlib and timezones, again
On Mon, Oct 1, 2012 at 10:47 AM, Lennart Regebro wrote: > A year is no age for a Python installation. A customer of mine has one > website developed in 2003, still running on the same server. It runs Python > 2.3, I don't remember which version, but I'd be surprised if it is 2.3.7 > from 2008. Right. If they don't keep their Python up-to-date, why would they bother with their tzupdate? My point is that there is not much of a difference in the incentive for upgrading your timezone data whether an initial version of it came with Python or not. Having to manually install it might make you slightly more aware that it helps if you upgrade it once in a while, but it seems more likely to be a fire and forget type of operation, in which case it's basically the same as shipping a version of the timezone data with Python (which is much easier, of course). To put it crudely, you seem to think that most developers keep careful track of what packages they need for their apps and actively assess the risk for upgrading each of the packages involved. On the other hand, I would assume more developers just get something working and then fix any bugs that come up. Cheers, Dirkjan ___ 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] Stdlib and timezones, again
On Mon, Oct 1, 2012 at 9:02 AM, Lennart Regebro wrote: > I don't want to default to a database that is guaranteed to be out of date. > I don't see the purpose. This is also why I'm skeptical at including the > data on Windows. I think that would be a little too pure to be practical. There are many practical usages of tz data that would work fine with a year-old timezone database. Personally, I'd want to not ship any tzdata with non-Windows Python packages on the assumption that they have good up-to-date OS tzdata (or it should be easy to disable it in the configure phase). Also, I wonder if it would be possible to select the copy of the data that is the most recent (e.g. on Unix, pick the OS version if tzupdate is installed but older than the OS version). Cheers, Dirkjan ___ 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] Stdlib and timezones, again
On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou wrote: > Can't we simply include the Olson database in Windows installers? We probably can, but the problem is that it's updated quite often (for example, in 2011, there were about 14 releases; in 2009, there were 21). So you'd want to have a mechanism to override the data that is included in the stdlib. Cheers, Dirkjan ___ 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] Stdlib and timezones, again
On Sun, Sep 30, 2012 at 2:47 PM, Lennart Regebro wrote: > What do you say? Is this a path worth pursuing? +1. It's the kind of low-level thing that should be solved in the stdlib as far as possible, and the pytz interface is as stable as the stdlib's. Cheers, Dirkjan ___ 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] Better HTTP 1.1 support in http.server?
On Mon, Sep 24, 2012 at 6:39 PM, Christian Heimes wrote: > You proposed gave me another idea. What do you think about SPDY support > in the stdlib? It's the next step after HTTP 1.1. I'd wait it out a bit. SPDY is currently iterating, and there's an effort to define HTTP 2 that will likely supersede SPDY (and may incorporate many of its ideas). http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI On the other hand, some WebSockets support might be useful. Cheers, Dirkjan ___ 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] Status of packaging in 3.3
On Wed, Jun 20, 2012 at 10:55 AM, Tarek Ziadé wrote: > So I prefer to hold it and have a solid implementation in the stldib. The > only thing I am asking is to retain ourselves to do *anything* in distutils > and continue to declare it frozen, because I know it will be tempting to do > stuff there... That policy has been a bit annoying. Gentoo has been carrying patches forever to improve compilation with C++ stuff (mostly about correctly passing on environment variables), and forward-porting them on every release gets tedious, but the packaging/distutils2 effort has made it harder to get them included in plain distutils. I understand there shouldn't be crazy patching in distutils, but allowing it to inch forward a little would make the lives of the Gentoo Python team easier, at least. Cheers, Dirkjan ___ 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] Status of packaging in 3.3
On Tue, Jun 19, 2012 at 11:46 PM, Éric Araujo wrote: > I don’t think (a) would give us enough time; we really want a few months > (and releases) to hash out the API (most notably with the pip and buildout > developers) and clean the bdist situation. Likewise (c) would require > developer (my) time that is currently in short supply. (b) also requires > time and would make development harder, not to mention probable user pain. > This leaves (d), after long reflection, as my preferred choice, even though > I disliked the idea at first (and I fully expect Tarek to feel the same > way). It's a pity, but it sounds like the way to go. This may be crazy, but just idly wondering: is there an opportunity for the PSF to make things better by throwing some money at it? Packaging appears to be one of those Hard problems, it might be a good investment. Cheers, Dirkjan ___ 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] Issue 2736: datetimes and Unix timestamps
On Tue, Jun 5, 2012 at 5:07 PM, Guido van Rossum wrote: > In fact, we might go further and define fromtimestamp() to do the same > thing. Then the only difference between the two would be what timezone > they use if there is *no* tzinfo. That's fine with me. Yeah, that sounds good. Cheers, Dirkjan ___ 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] Issue 2736: datetimes and Unix timestamps
On Tue, Jun 5, 2012 at 3:45 PM, Guido van Rossum wrote: > For datetimes with tzinfo, dt.totimestamp() should return (dt - > epoch).total_seconds() where epoch is > datetime.datetime.fromtimestamp(0, datetime.timezone.utc); for > timezones without tzinfo, a similar calculation should be performed > assuming local time. The utctotimestamp() method should insist that dt > has no tzinfo and then do a similar calculation again assuming the > implied UTC timezone. It would be nice if utctotimestamp() also worked with datetimes that have tzinfo set to UTC. And while I don't think we really need it, if there are concerns that some other epochs may be useful, we could add an optional epoch argument. Cheers, Dirkjan ___ 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] Issue 2736: datetimes and Unix timestamps
On Mon, Jun 4, 2012 at 2:11 PM, Nick Coghlan wrote: > My perspective is that if I'm dealing with strictly absolute time, I > should only need one import: datetime > > If I'm dealing strictly with relative time, I should also only need > one import: time Can you define "relative time" here? The term makes me think of things like timedelta. Personally, I would really like not having to think about the time module at all, except if I wanted to go low-level (e.g. get a Unix timestamp from scratch). Cheers, Dirkjan ___ 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] Issue 2736: datetimes and Unix timestamps
I recently opened issue14908. At work, I have to do a bunch of things with dates, times and timezones, and sometimes Unix timestamps are also involved (largely for easy compatibility with legacy APIs). I find the relative obscurity when converting datetimes to timestamps rather painful; IMO it should be possible to do everything I need straight from the datetime module objects, instead of having to involve the time or calendar modules. Anyway, I was pointed to issue 2736, which seems to have got a lot of discouraged core contributors (Victor, Antoine, David and Ka-Ping, to name just a few) up against Alexander (the datetime maintainer, AFAIK). It seems like a fairly straightforward case of practicality over purity: Alexander argues that there are "easy" one-liners to do things like datetime.totimestamp(), but most other people seem to not find them so easy. They've since been added to the documentation at least, but I would like to see if there is consensus on python-dev that adding a little more timestamp support to datetime objects would make sense. I hope this won't become another epic issue like the last time-related issue... Cheers, Dirkjan ___ 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] Point of building without threads?
On Mon, May 7, 2012 at 9:49 PM, Antoine Pitrou wrote: > I guess a long time ago, threading support in operating systems wasn't > very widespread, but these days all our supported platforms have it. > Is it still useful for production purposes to configure > --without-threads? Do people use this option for something else than > curiosity of mind? Gentoo (of course) allows users to build Python without threads; I'm not aware of anyone depending on that, but I sent out a quick question to gentoo-dev. Cheers, Dirkjan ___ 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] Does trunk still support any compilers that *don't* allow declaring variables after code?
On Wed, May 2, 2012 at 10:43 AM, Larry Hastings wrote: > Do we officially support any C compilers that *don't* permit "intermingled > variable declarations and code"? Do we *unofficially* support any? And if > we do, what do we gain? This might be of interest: http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/?nope Specifically, apparently MSVC 2010 supports variable declarations in the middle of a block in C. Also, since full C99 support won't be coming to MSVC, perhaps Python should move to compiling in C++ mode? Cheers, Dirkjan ___ 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] [Python-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed
On Fri, Mar 23, 2012 at 09:26, Stefan Krah wrote: > I'll add the --with-system-libmpdec option with the caveat that > changes will probably make it first into the libmpdec shipped > with Python, see also: > > http://bugs.python.org/issue7652#msg155744 Sounds good, thanks! Cheers, Dirkjan ___ 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] [Python-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed
On Wed, Mar 21, 2012 at 23:22, Victor Stinner wrote: >>> http://hg.python.org/cpython/rev/730d5357 >>> changeset: 75850:730d5357 >>> user: Stefan Krah >>> date: Wed Mar 21 18:25:23 2012 +0100 >>> summary: >>> Issue #7652: Integrate the decimal floating point libmpdec library to speed >>> up the decimal module. Performance gains of the new C implementation are >>> between 12x and 80x, depending on the application. As a Python user, this looks really cool, thanks! As a packager, is the libmpdec library used elsewhere? For Gentoo, we generally prefer to package libraries separately and have Python depend on them. From the site, it seems like you more or less wrote libmpdec for usage in Python, but if it's general-purpose and actually used in other software, it would be nice if Python grew a configure option to make it use the system libmpdec. Cheers, Dirkjan ___ 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] Playing with a new theme for the docs
On Wed, Mar 21, 2012 at 07:00, Georg Brandl wrote: > OK, that seems to be the main point people make... let me see if I can > come up with a better compromise. Would it be possible to limit the width of the page? On my 1920px monitor, the lines get awfully long, making them harder to read. Cheers, Dirkjan ___ 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] Add a frozendict builtin type
On Mon, Feb 27, 2012 at 19:53, Victor Stinner wrote: > A frozendict type is a common request from users and there are various > implementations. There are two main Python implementations: Perhaps this should also detail why namedtuple is not a viable alternative. Cheers, Dirkjan ___ 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] PEP czar for PEP 3144?
On Mon, Feb 20, 2012 at 16:27, Antoine Pitrou wrote: >> Should it be net.ipaddress instead of just ipaddress? >> >> Somewhat nested is better than fully flat. > > IMHO, nesting without a good, consistent, systematic categorization > leads to very unpleasant results (e.g. "from urllib.request import > urlopen"). > > Historically, our stdlib has been flat and I think it should stay so, > short of redoing the whole hierarchy. > > (note this has nothing to do with the possible implementation of > modules as packages, such as unittest or importlib) I thought Python 3 already came with a net package, but apparently that plan has long been discarded. So I retract my suggestion. Cheers, Dirkjan ___ 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] PEP czar for PEP 3144?
On Mon, Feb 20, 2012 at 14:23, Nick Coghlan wrote: > I don't personally think the module API needs the provisional > disclaimer as the core functionality has been tested for years in > ipaddr and the API changes in ipaddress are just cosmetic ones either > for PEP 8 conformance, or to make the API map more cleanly to the > underlying networking concepts. However, I'd be willing to include > that proviso if anyone else has lingering concerns. Should it be net.ipaddress instead of just ipaddress? Somewhat nested is better than fully flat. Cheers, Dirkjan ___ 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] PEP 410 (Decimal timestamp): the implementation is ready for a review
On Wed, Feb 15, 2012 at 10:11, "Martin v. Löwis" wrote: >> My primary concern with the PEP is adding to users confusion when they have >> to >> handle (at least) 5 different types[*] that represent time in Python. > > I agree with Barry here (despite having voiced support for using Decimal > before): datetime.datetime *is* the right data type to represent time > stamps. If it means that it needs to be improved before it can be used > in practice, then so be it - improve it. > > I think improving datetime needs to go in two directions: > a) arbitrary-precision second fractions. My motivation for > proposing/supporting Decimal was that it can support arbitrary > precision, unlike any of the alternatives (except for using > numerator/denominator pairs). So just adding nanosecond resolution > to datetime is not enough: it needs to support arbitrary decimal > fractions (it doesn't need to support non-decimal fractions, IMO). > b) distinction between universal time and local time. This distinction > is currently blurred; there should be prominent API to determine > whether a point-in-time is meant as universal time or local time. > In terminology of the datetime documentation, there needs to be > builtin support for "aware" (rather than "naive") UTC time, even > if that's the only timezone that comes with Python. +1. And adding stuff to datetime to make it easier to get a unix timestamp out (as proposed by Victor before, IIRC) would also be a good thing in my book. I really want to be able to handle all my date+time needs without ever importing time or calendar. Cheers, Dirkjan ___ 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] PEP 410 (Decimal timestamp): the implementation is ready for a review
FWIW, I'm with Barry on this; doing more with the datetime types seems preferable to introducing yet more different stuff to date/time handling. On Mon, Feb 13, 2012 at 19:33, Victor Stinner wrote: > Oh, I forgot to mention my main concern about datetime: many functions > returning timestamp have an undefined starting point (an no timezone > information ), and so cannot be converted to datetime: > - time.clock(), time.wallclock(), time.monotonic(), > time.clock_gettime() (except for CLOCK_REALTIME) > - time.clock_getres() > - signal.get/setitimer() > - os.wait3(), os.wait4(), resource.getrusage() > - etc. > > Allowing datetime.datetime type just for few functions (like > datetime.datetime or time.time) but not the others (raise an > exception) is not an acceptable solution. It seems fairly simple to suggest that the functions with an undefined starting point could return a timedelta instead of a datetime? >> * datetime.datetime has ordering issues with daylight saving time (DST) in >> the duplicate hour of switching from DST to normal time. >> >> Sure, but only for timezone-ful datetimes, right? > > I don't know enough this topic to answer. Martin von Loewis should > answer to this question! Yes, this should only be an issue for dates with timezones. >> * datetime.datetime is not as well integrated than Epoch timestamps, some >> functions don't accept this type as input. For example, os.utime() expects >> a tuple of Epoch timestamps. >> >> So, by implication, Decimal is better integrated by virtue of its ability to >> be coerced to floats and other numeric stack types? > > Yes. decimal.Decimal is already supported by all functions accepting > float (all functions expecting timestamps). I suppose something like os.utime() could be changed to also accept datetimes. >> If it really is impossible or suboptimal to build high resolution datetimes >> and timedeltas, and to use them in these APIs, then at the very least, the >> PEP >> needs a stronger rationale for why this is. > > IMO supporting nanosecond in datetime and timedelta is an orthogonal issue. Not if you use it to cast them aside for this issue. ;) Cheers, Dirkjan ___ 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] folding cElementTree behind ElementTree in 3.3
On Wed, Feb 8, 2012 at 08:37, Stefan Behnel wrote: > I didn't get a response from him to my e-mails since early 2010. Maybe > others have more luck if they try, but I don't have the impression that > waiting another two years gets us anywhere interesting. > > Given that it was two months ago that I started the "Fixing the XML > batteries" thread (and years since I brought up the topic for the first > time), it seems to be hard enough already to get anyone on python-dev > actually do something for Python's XML support, instead of just actively > discouraging those who invest time and work into it. I concur. It's important that we consider Fredrik's ownership of the modules, but if he fails to reply to email and doesn't update his repositories, there should be enough cause for python-dev to go on and appropriate the stdlib versions of those modules. Cheers, Dirkjan ___ 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] requirements for moving __import__ over to importlib?
On Tue, Feb 7, 2012 at 21:24, Barry Warsaw wrote: > Identifying the use cases are important here. For example, even if it were a > lot slower, Mailman wouldn't care (*I* might care because it takes longer to > run my test, but my users wouldn't). But Bazaar or Mercurial users would care > a lot. Yeah, startup performance getting worse kinda sucks for command-line apps. And IIRC it's been getting worse over the past few releases... Anyway, I think there was enough of a python3 port for Mercurial (from various GSoC students) that you can probably run some of the very simple commands (like hg parents or hg id), which should be enough for your purposes, right? Cheers, Dirkjan ___ 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] PEP 407: New release cycle and introducing long-term support versions
On Tuesday, January 17, 2012, Antoine Pitrou wrote: > We would like to propose the following PEP to change (C)Python's release > cycle. Discussion is welcome, especially from people involved in the > release process, and maintainers from third-party distributions of > Python. As a Gentoo packager, this would mean much more work for us, unless all the non-LTS releases promised to be backwards compatible. I.e. the hard part for us is managing all the incompatibilities in other packages, compatibility with Python. As a user of Python, I would rather dislike the change from 18 to 24 months for LTS release cycles. And the limiting factor for my use of Python features is largely old Python versions still in use, not the availability of newer features in the newest Python. So I'm much more interested in finding ways of improving 2.7/3.2 uptake than adding more feature releases. I also think that it would be sensible to wait with something like this process change until the 3.x adoption curve is much further along. Cheers, Dirkjan > Regards > > Antoine. > > > PEP: 407 > Title: New release cycle and introducing long-term support versions > Version: $Revision$ > Last-Modified: $Date$ > Author: Antoine Pitrou , >Georg Brandl , >Barry Warsaw > Status: Draft > Type: Process > Content-Type: text/x-rst > Created: 2012-01-12 > Post-History: > Resolution: TBD > > > Abstract > > > Finding a release cycle for an open-source project is a delicate > exercise in managing mutually contradicting constraints: developer > manpower, availability of release management volunteers, ease of > maintenance for users and third-party packagers, quick availability of > new features (and behavioural changes), availability of bug fixes > without pulling in new features or behavioural changes. > > The current release cycle errs on the conservative side. It is > adequate for people who value stability over reactivity. This PEP is > an attempt to keep the stability that has become a Python trademark, > while offering a more fluid release of features, by introducing the > notion of long-term support versions. > > > Scope > = > > This PEP doesn't try to change the maintenance period or release > scheme for the 2.7 branch. Only 3.x versions are considered. > > > Proposal > > > Under the proposed scheme, there would be two kinds of feature > versions (sometimes dubbed "minor versions", for example 3.2 or 3.3): > normal feature versions and long-term support (LTS) versions. > > Normal feature versions would get either zero or at most one bugfix > release; the latter only if needed to fix critical issues. Security > fix handling for these branches needs to be decided. > > LTS versions would get regular bugfix releases until the next LTS > version is out. They then would go into security fixes mode, up to a > termination date at the release manager's discretion. > > Periodicity > --- > > A new feature version would be released every X months. We > tentatively propose X = 6 months. > > LTS versions would be one out of N feature versions. We tentatively > propose N = 4. > > With these figures, a new LTS version would be out every 24 months, > and remain supported until the next LTS version 24 months later. This > is mildly similar to today's 18 months bugfix cycle for every feature > version. > > Pre-release versions > > > More frequent feature releases imply a smaller number of disruptive > changes per release. Therefore, the number of pre-release builds > (alphas and betas) can be brought down considerably. Two alpha builds > and a single beta build would probably be enough in the regular case. > The number of release candidates depends, as usual, on the number of > last-minute fixes before final release. > > > Effects > === > > Effect on development cycle > --- > > More feature releases might mean more stress on the development and > release management teams. This is quantitatively alleviated by the > smaller number of pre-release versions; and qualitatively by the > lesser amount of disruptive changes (meaning less potential for > breakage). The shorter feature freeze period (after the first beta > build until the final release) is easier to accept. The rush for > adding features just before feature freeze should also be much > smaller. > > Effect on bugfix cycle > -- > > The effect on fixing bugs should be minimal with the proposed figures. > The same number of branches would be simultaneously open for regular > maintenance (two until 2.x is terminated, then one). > > Effect on workflow > -- > > The workflow for new features would be the same: developers would only > commit them on the ``default`` branch. > > The workflow for bug fixes would be slightly updated: developers would > commit bug fixes to the current LTS branch (for example ``3.3``) and > then merge them into ``default``. > _
Re: [Python-Dev] Fwd: Anyone still using Python 2.5?
On Wed, Dec 21, 2011 at 08:16, Chris Withers wrote: > What's the general consensus on supporting Python 2.5 nowadays? > > Do people still have to use this in commercial environments or is > everyone on 2.6+ nowadays? This seems rather off-topic for python-dev. FWIW, on Gentoo we're just now getting to dropping 2.4, so we'll support 2.5 quite a bit longer. That's also the tendency I see from the ecosystem, at least insofar as I notice. On the other hand, we've had 2.7 as the default python on our stable branch since March 2011. I also know Mercurial is still supporting 2.4 (they tend to be conservative about dropping support for old releases). Cheers, Dirkjan ___ 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] cpython (3.2): don't mention implementation detail
On Tue, Dec 20, 2011 at 11:27, Terry Reedy wrote: > And I remember that Guido has > asked that the manual not discuss big O() > behavior of the methods of builtin classes. Do you know when/where he did that? It seems useful to know that on CPython, list.insert(0, x) will become slow as the list grows... It probably shouldn't be upfront, but O() hints for some of the core stuff seems useful (though again, in some cases they should probably be limited to CPython). Cheers, Dirkjan ___ 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] cpython (3.2): don't mention implementation detail
On Tue, Dec 20, 2011 at 11:08, Antoine Pitrou wrote:
>> If this documentation is to be used by other python implementations,
>> then mentions of performance are outright harmful, since the
>> performance characteristics differ quite drastically. Written in C is
>> also not a part of specification as far as I know :)
>
> But that's basically the only reason to invoke the
> `operator.attrgetter("foo")` ugliness, instead of writing the explicit
> and obvious `lambda x: x.foo`.
> So not mentioning that it provides a speed benefit on CPython hides the
> primary reason for using the operator module. Overwise it's just a bunch
> of useless wrappers.
So the question is if the docs are Python documentation or CPython
documentation? On PyPy, I'm guessing lambda x: x.foo might (some day)
be just as fast as operator.attrgetter("foo").
> Implementation details *deserve* to be documented when they have an
> impact on behaviour (including performance / resource usage). Python is
> not just a platonic ideal. Do you suggest we also remove this part:
> http://docs.python.org/dev/library/io.html#performance
> ?
I agree that it's good to document some implementation details, but it
seems like the paragraph, as it was before, documented too many
details. It seems like a paragraph that mentions the specificity of
this aspect for CPython and omits the reference to C as the VM
implementation should be acceptable to all parties.
Cheers,
Dirkjan
___
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] A new dict for Xmas?
On Sat, Dec 17, 2011 at 12:53, Maciej Fijalkowski wrote: > Note that unlike some other more advanced approaches, slots do change > semantics. There are many cases out there where people would stuff > arbitrary things on stdlib objects and this works fine without > __slots__, but will stop working as soon as you introduce them. A > change from no slots to using slots is not only a performance issue. Yeah... This whole idea reeks of polymorphic inline caches (called "shapes" or "hidden classes" in SpiderMonkey and v8, respectively), where they dynamically try to infer what kind of class an object has, such that the __slots__ optimization can be done without making it visible in the semantics. The Unladen Swallow guys mention in their ProjectPlan that the overhead of opcode fetch/dispatch makes that hard, though. Cheers, Dirkjan ___ 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] French sprint this week-end
On Fri, Dec 16, 2011 at 10:17, Eli Bendersky wrote: > Do we have buildbots that build Python with Clang instead of GCC? The reason > I'm asking is that Clang's diagnostics are usually better, and fixing all > its warnings could nicely complement fixing GCC's qualms. The box running my buildslave has clang installed, so someone with access to the buildmaster could probably set that up without too much trouble. Cheers, Dirkjan ___ 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] Fixing the XML batteries
On Fri, Dec 9, 2011 at 09:02, Stefan Behnel wrote: > a) The stdlib documentation should help users to choose the right tool right > from the start. > b) cElementTree should finally loose it's "special" status as a separate > library and disappear as an accelerator module behind ElementTree. An at least somewhat informed +1 from me. The ElementTree API is a very good way to deal with XML from Python, and it deserves to be promoted over the included alternatives. Let's deprecate the NiCad batteries and try to guide users toward the Li-Ion ones. Cheers, Dirkjan ___ 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] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
On Wed, Nov 23, 2011 at 13:21, Stephen J. Turnbull wrote: > > Problems like what? > > Like those I explained later in the post, which you cut. But I'll They were in a later post, I didn't cut them. :) > > Please create a connection to your distro by filing bugs as you > > encounter them? > > No, thank you. File bugs, maybe, although most of the bugs I > encounter in Gentoo are already in the database (often with multiple > regressions going back a year or more), I could do a little more of > that. (Response in the past has not been encouraging.) But I don't > have time for distro politics. I'm sorry for the lack of response in the past. I looked at Gentoo's Bugzilla and didn't find any related bugs you reported or were CC'ed on, can you name some of them? > Is lack of Python 3-readiness considered a bug by Gentoo? Definitely. Again, we are trying to hard to make things better, but there's a lot to do and going through version bumps sometimes wins out over addressing the hard problems. Be assured, though, that we're also trying to make progress on the latter. If you're ever on IRC, come hang out in #gentoo-python, where distro politics should be minimal and the crew is generally friendly and responsive. Cheers, Dirkjan ___ 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] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
On Tue, Nov 22, 2011 at 17:41, Stephen J. Turnbull wrote: > This is still a big mess in Gentoo and MacPorts, though. MacPorts > hasn't done anything about ceating a transition infrastructure AFAICT. > Gentoo has its "eselect python set VERSION" stuff, but it's very > dangerous to set to a Python 3 version, as many things go permanently > wonky once you do. (So far I've been able to work around problems > this creates, but it's not much fun.) Problems like what? > I don't have any connections to the distros, so can't really offer to > help directly. I think it might be a good idea for users to lobby > (politely!) their distros to work on the transition. Please create a connection to your distro by filing bugs as you encounter them? The Gentoo Python team is woefully understaffed (and I've been busy with some Real Life things, although that should improve in a couple more weeks), but we definitely care about providing an environment where you can successfully run python2 and python3 in parallel. Cheers, Dirkjan ___ 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] patch metadata - to use or not to use?
On Sat, Nov 19, 2011 at 20:41, Petri Lehtinen wrote: >> Generally speaking, it's more useful for the checkin metadata to >> reflect who actually did the checkin, since that's the most useful >> information for the tracker and buildbot integration. > > At least in git, the commit metadata contains both author and > committer (at least if they differ). Maybe mercurial has this too? It does not. Personally, I find it more appropriate to have the original patch author in the "official" metadata, mostly because I personally find it very satisfying to see my name in the changelog on hgweb and the like. My own experience with that makes me think that it's probably helpful in engaging contributors. Cheers, Dirkjan ___ 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] Bring new features to older python versions
On Sat, Oct 8, 2011 at 21:47, Toshio Kuratomi wrote: > I have some similar code in kitchen: > http://packages.python.org/kitchen/api-overview.html It also sounds similar to six: http://pypi.python.org/pypi/six Avoid all the duplicate efforts would certainly make sense. Cheers, Dirkjan ___ 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] PEP categories (was Re: PEP 393 review)
On Mon, Aug 29, 2011 at 18:24, Barry Warsaw wrote: >>Also, this PEP makes me wonder if there should be a way to distinguish >>between language PEPs and (CPython) implementation PEPs, by adding a >>tag or using the PEP number ranges somehow. > > I've thought about this, and about a similar split between language changes > and stdlib changes (i.e. new modules such as regex). Probably the best thing > to do would be to allocate some 1000's to the different categories, like we > did for the 3xxx Python 3k PEPS (now largely moot though). Allocating 1000's seems sensible enough to me. And yes, the division between recents 3x and non-3x PEPs seems quite arbitrary. Cheers, Dirkjan P.S. Perhaps the index could list accepted and open PEPs before meta and informational? And maybe reverse the order under some headings, for example in the finished category... ___ 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] PEP 393 review
On Sun, Aug 28, 2011 at 21:47, "Martin v. Löwis" wrote: > result strings. In PEP 393, a buffer must be scanned for the > highest code point, which means that each byte must be inspected > twice (a second time when the copying occurs). This may be a silly question: are there things in place to optimize this for the case where two strings are combined? E.g. highest character in combined string is max(highest character in either of the strings). Also, this PEP makes me wonder if there should be a way to distinguish between language PEPs and (CPython) implementation PEPs, by adding a tag or using the PEP number ranges somehow. Cheers, Dirkjan ___ 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] Extending os.chown() to accept user/group names
On Wed, May 25, 2011 at 15:41, Barry Warsaw wrote: > I think it would be a nice feature, and I can see the conflict. OT1H you want > to keep os.chown() a thin wrapper, but OTOH you'd rather not have to add a > new, arguably more difficult to discover, function. Given those two choices, > I still think I'd come down on adding a new function and shutil.chown() seems > an appropriate place for it. Right. Please add a mention of shutil.chown() to the os.chown() docs, though. Cheers, Dirkjan ___ 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] Bug in json (the format and the module)
On Tue, May 17, 2011 at 19:40, Jeremy Dunck wrote: > So, to start with, is there a maintainer for the json module, or how > should I go about discussing implementing this solution? Your subject states that there is an actual bug in the json module, but your message fails to mention any actual bug. Is this what you mean? Python 2.7.1 (r271:86832, Mar 28 2011, 09:54:04) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import json >>> print json.dumps(u'foo\u2028bar') "foo\u2028bar" Cheers, Dirkjan ___ 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] Status of json (simplejson) in cpython
On Sat, Apr 16, 2011 at 16:19, Antoine Pitrou wrote: > What you're proposing doesn't address the question of who is going to > do the ongoing maintenance. Bob apparently isn't interested in > maintaining stdlib code, and python-dev members aren't interested in > maintaining simplejson (assuming it would be at all possible). Since > both groups of people want to work on separate codebases, I don't see > how sharing a single codebase would be possible. >From reading this thread, it seems to me like the proposal is that Bob maintains a simplejson for both 2.x and 3.x and that the current stdlib json is replaced by a (trivially changed) version of simplejson. Cheers, Dirkjan ___ 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] Impaired Usability of the Mercurial Source Viewer
On Fri, Apr 1, 2011 at 02:30, Antoine Pitrou wrote: > This is something you need to discuss with the Mercurial project. > See http://mercurial.selenic.com/bts/ and > http://mercurial.selenic.com/wiki/ContributingChanges There's a lot you can change by just starting a new set of templates (with Mercurial's templating language). I even wrote an extension that'll let you use Jinja for the templating, so it shouldn't be hard to make changes here -- changes like Raymond proposes most certainly don't require code changes inside Mercurial. Cheers, Dirkjan ___ 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] Dict access with double-dot (syntactic sugar)
On Thu, Mar 24, 2011 at 12:40, Jameson Quinn wrote: > "class attrdict" is a perennial dead-end for intermediate pythonistas who > want to save 3 characters/5 keystrokes for item access. Other languages such > as javascript allow "somedict.foo" to mean the same as "somedict['foo']", so > why not python? Well, there are a number of reasons why not, beginning with > all the magic method names in python. This should go on python-ideas. Cheers, Dirkjan ___ 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] Workflow proposal
On Wed, Mar 23, 2011 at 12:39, John Arbash Meinel wrote: > Just as an aside, and I might be wrong. But reading through what strip > does, (and from my knowledge of the disk layout) it can't actually be > atomic. So if you kill it at the wrong time, it will have corrupted your > repository. > > At least, that is from what I can tell. Which is that it has to rewrite > each file history to omit the revisions you are stripping, and then > rewrite the revision history to do the same. It would be possible to be > 'stable' if you wrote a write-ahead-log and did all the work on the > side, and then any client that tries to read or write to the repository > finishes up the steps. But the individual file histories refer to the > global revision history (by index), so you don't have a 'top-down' view > that makes it all atomic by changing the top level object to point to > the new lower level objects. The reason that shouldn't happen is the ordering. If we strip the changelog first (what you call the global revision history), other clients won't be able to "find" the any file-level revisions only referenced by the revision just stripped, so it should be atomic. Cheers, Dirkjan ___ 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] I am now lost - committed, pulled, merged, what is "collapse"?
On Wed, Mar 23, 2011 at 04:39, wrote: > > Dirkjan> The right solution here is to use different clones for > Dirkjan> different projects/areas. The proposed interpreter/stdlib > Dirkjan> split, for example, might reduce contention (although I imagine > Dirkjan> it would reduce it only by a little bit?). > > How about splitting the documentation and the code into separate > repositories (I believe that is the proper term, though perhaps "clone" is - > Dirkjan is the expert)? That might work. I guess the stdlib/interpreter split should also think about how to split up the docs. And yes, clone might be a better word to use in this context. The repository word is slightly overloaded, in that it can be used both for clone, or to distinguish the .hg part from the working dir part of a clone, for example. > Moving onto something related, but different, I find that people bandy about > terms which I just can't seem to find defined very well anywhere I've > looked. The Mercurial Glossary (http://mercurial.selenic.com/wiki/Glossary) > would seem to be the obvious place to look, but it doesn't define the terms > "branch" or "clone" (nor does it obviously differentiate a "named branch" > from any other kind of "branch"). I hesitate to overload those words with > the meanings I've acquired using Subversion and CVS, because they will > probably be wrong in subtle ways. Also, "rebase" is not defined in the > glossary. One problem with branches in DVCS is that there are so many kinds of them. The SVN repository, for example, would now be reflected by all of the clones of python-dev lineage (starting with the same changeset) everywhere. Each of these clones represent a branch, in the sense that someone can commit there and thus deviate from all other repositories. If you commit twice from the same parent changeset in your clone, you end up with two heads (on the same named branch), which are also separate branches in the distributed global python-dev DAG. And all of these are "unnamed" branches, possibly residing on the same named branch... > There are clearly lots of Mercurial-related documents on the web. There is > no editorial review of their quality other than Google page rank. Is there a > prioritized list of stuff one should read? The hg wiki is a good resource, but can be a bit disorganized. You might also want to read the hgbook, which is slightly outdated but should have thorough explanations. It's also available in dead-tree form. Cheers, Dirkjan ___ 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] I am now lost - committed, pulled, merged, what is "collapse"?
On Wed, Mar 23, 2011 at 03:12, Stephen J. Turnbull wrote: > No, software engineering scales up to a point, then it breaks and you > need a serialization scheme. The problem is not the DVCS, it's the > demand for a *centralized*, authoritative, safe, stable version. DVCS > can scale at least to Linux kernel pace if you only ask for > centralized authoritative. DVCS is "No Silver Bullet", it only > helps with some accidental costs of development. It doesn't help with > the costs of review and testing. Yeah, Linux employs the other solution here (which Mercurial also uses, in fact, for development of Mercurial itself): only one person pushes to the central repository, that person pulls from other "staging" repositories as he is aware of changes being made. > There are in fact problems with the current generation of DVCSes. > Lack of plists on commits, for example. You'd like to have a "tested" > property, in fact two of them (one for the committer, one for the > buildbots). You'd like to have a "checkpoint" property, which commits > would by default be ignored by "log" and "bisect". You'd like to have > an "issues" property, a list of issues applicable to this commit. But > again, these would only reduce accidental costs. Mercurial does in fact have a mechanism to attach arbitrary metadata to changesets (the extra dictionary), but there's no easy access from the command-line. One could also argue that this is basically just a special case of smart commit message formatting, which python-dev already does, and could extend. (For example, Mozilla sometimes closes their tree to general commits, but then has a CLOSED tag that can be put in a commit message to override that.) Cheers, Dirkjan ___ 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] I am now lost - committed, pulled, merged, what is "collapse"?
On Tue, Mar 22, 2011 at 21:56, Paul Moore wrote: > On 22 March 2011 20:44, Dirkjan Ochtman wrote: >> The right solution here is to use different clones for different >> projects/areas. > > I'm not trolling here, just trying to learn something about Mercurial. > Would having separate clones for the various releases (2.7, 3.1, 3.2, > ...) rather than named branches, reduce contention? I imagine it would > make porting patches between versions harder, on the other hand...? Probably not really. In particular, since many changes are forward-ported across branches, you'll still need to push to each of the release branches... I'm not sure what the ratio for pure-feature vs. bugfix is; if there is a significant number of pure-feature patches (i.e. not on any of the release branches), it might help to separate all of the release branches from the default branch. Cheers, Dirkjan ___ 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] I am now lost - committed, pulled, merged, what is "collapse"?
On Tue, Mar 22, 2011 at 19:29, R. David Murray wrote: > Note that svnmerge broke at exactly the same scale point, for exactly the > same reason: every svnmerge touched root properties, thereby effectively > serializing access to the tree. There were lots of curses from people > trying to svnmerge at the sprints in previous years. The right solution here is to use different clones for different projects/areas. The proposed interpreter/stdlib split, for example, might reduce contention (although I imagine it would reduce it only by a little bit?). Supposedly other meaningful subdivisions exist. Then people working on those projects don't keep the central repo occupied, instead only merging their project tree into the main tree on some delayed schedule (say, weekly). This is something that Mozilla has been doing, for example, their JS interpreter is now developed in a separate clone. It might also be a good match for sprints, where one room could have its own repo and the other room has a different repo. Or all the packaging sprinters push to their cpython-packaging repo. Cheers, Dirkjan ___ 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] Using feature branches for local development
On Sun, Mar 13, 2011 at 12:25, Nick Coghlan wrote: > I'm experimenting with creating some local branches for things I'd > like to work on during the sprints this week, and have a couple of > questions about the associated workflow. By local branches, do you mean named branches (using the hg branch command to set a branch name), or unnamed extra heads/extra clones? > 1. While the feature branches are active, is it correct that I can't > use a bare "hg push" any more, since I don't want to push the feature > branches to hg.python.org? Instead, I need to name all the branches I > want to push explicitly. The easy solution is to use a local clone and not push from it to hg.p.o at all. hg push does indeed push all branches (named and unnamed) by default. > 2. Once I'm done with the feature branch, I need to nuke it somehow > (e.g. by enabling the mq extension to gain access to "hg strip" > command) You're implying you want to smash the feature branch down to a single patch? In that case, yeah. > If those are both accurate, I may actually create a new subclone, > leaving the main local repository with only the changes I actually > want to push upstream. That's the easy solution. The slightly harder, but more powerful, solution is to learn MQ. Cheers, Dirkjan ___ 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] v2.7 tag
On Tue, Mar 8, 2011 at 10:45, Stefan Krah wrote: > Hi, > > I can't update to v2.7 in the new cpython repository: > > $ hg up v2.7 > abort: unknown revision 'v2.7'! > > Am I missing something here? My goal is to get the same directory state > as from this command: > > svn co http://svn.python.org/projects/python/tags/r27 Did you by any chance use hg clone -rv2.7? That's a common gotcha: that will only clone the repository up to but not including the tagging changeset (the tip in the clone will be the tagged changeset), meaning a subsequent update to the tag will fail. Cheers, Dirkjan ___ 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] hooks: Hopefully fix the issue where notification of merges to buildbot
On Sun, Mar 6, 2011 at 02:38, Antoine Pitrou wrote: > For the record, the reason these emails look a bit strange (and appear > to be pushed by Dirkjan (sorry)) is that they were done directly on the > server with the settings of the local user "hg". FWIW, I have a tiny extension at work that can set the user depending on the private key used to log in. I could show you the code if it's helpful (it'll probably need some refinements to be robust enough). Cheers, Dirkjan ___ 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] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 09:25, "Martin v. Löwis" wrote: > If there are hundreds of them, it's far from trivial. I don't even know > how to find out which one to convert. Right, I mostly mean it's trivial for Antoine or Georg to extract into a clone (at least that's how I was planning to do it, not sure what their idea is). Cheers, Dirkjan ___ 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] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 09:09, "Martin v. Löwis" wrote: > I think I would have liked the strategy of the PEP better (i.e. > create clones for feature branches, rather than putting all > in a single repository). Unnamed heads are trivial to convert to clones. Cheers, Dirkjan ___ 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] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 01:19, Antoine Pitrou wrote: > Georg and I have been working on converting the SVN repository to > Mercurial. We can now present you a test repository (actually, two). Sorry everyone for taking so long on the conversion. Looks like Antoine and Georg have more time and energy to spend on this than I do, so I will let them pick up my slack. Cheers, Dirkjan ___ 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] Actual Mercurial Roadmap for February (Was: svn outage on Friday)
On Fri, Feb 18, 2011 at 14:41, anatoly techtonik wrote: > Do you have a public list of stuff to be done (i.e. Roadmap)? > BTW, what is the size of Mercurial clone for Python repository? There is a TODO file in the pymigr repo (though I think that is currently inaccessible). I don't have a recent optimized clone to check the size of, yet. Cheers, Dirkjan ___ 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] svn outage on Friday
On Tue, Feb 15, 2011 at 09:30, "Martin v. Löwis" wrote: > I'm going to perform a Debian upgrade of svn.python.org on Friday, > between 9:00 UTC and 11:00 UTC. I'll be disabling write access during > that time. The outage shouldn't be longer than an hour. It seems hg is no longer installed on dinsdale, does that have anything to do with this? Cheers, Dirkjan ___ 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] svn outage on Friday
On Fri, Feb 18, 2011 at 00:17, "Martin v. Löwis" wrote: > I think it's fair to say that the project currently rests, lacking > a project lead. The most recent timeline is that conversion should > be completed by PyCon, and, failing that, should start at PyCon. It's not exactly resting; I've been pushing around the cvs2svn-converted tags to get them to behave sensibly, and I've been having good discussions with Antoine and Georg about several things we need to hash out in IRC. Sorry I haven't been doing more progress reports here. But yes, it would be nice if we could actually switch by PyCon, but at the very least there should be a fresh test repo and consensus on most of the workflow issues by PyCon (for those interested who live in Europe, I'm going to be at a hg sprint in Karlsruhe during the PyCon weekend). Cheers, Dirkjan ___ 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] devguide: Basic instructions on how to generate a patch with hg for non-committers.
On Mon, Feb 7, 2011 at 15:46, Antoine Pitrou wrote: > I'm not advocating anything in particular really. I think creating a > named branch "foo" (or a bookmark? I've never used them but it sounds > like they might do the trick) and then using "hg di -r py3k" to get the > diff against upstream is very reasonable. That's without any hg > extension activated. Yeah, I don't think we need rdiff. IIRC it isn't really maintained, either, just the basics to keep it working with new versions of hg. Cheers, Dirkjan ___ 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] Mercurial style patch submission (Was: MSI: Remove dependency from win32com.client module (issue4080047))
On Mon, Jan 31, 2011 at 22:50, anatoly techtonik wrote: > If you don't want to receive a stupid answer, why don't you read the > link and say what you don't like in this approach in a constructive > manner? Mercurial is a much smaller project, so it has different needs. It would be nice if you could respect the process the developers on any project have laid out for their project and assume they know what works best for them. Cheers, Dirkjan ___ 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] Backport troubles with mercurial
On Wed, Dec 29, 2010 at 10:53, Amaury Forgeot d'Arc wrote: > And http://hg.python.org/cpython/ probably needs an initial "dummy merge" > on every branch. Yes, the present delays are all about getting that right. Cheers, Dirkjan ___ 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] Porting Ideas
On Thu, Dec 2, 2010 at 20:24, Sridhar Ratnakumar wrote: > Also note that the dependency information is incomplete. Also, a python3 version of chardet is available (from the website only, looks like). Cheers, Dirkjan ___ 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] Mercurial Schedule
On Fri, Nov 19, 2010 at 15:56, Nick Coghlan wrote: > That's enough to make folks like me somewhat nervous as to whether or > not we're actually going to have a usable source control system come > December 12. Yes, I've been negligent about updating the PEP. I'll try do so next week. Georg, if you have time to update it a bit, that would be great as well. Cheers, Dirkjan ___ 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] Mercurial Schedule
On Wed, Nov 17, 2010 at 13:51, Jesus Cea wrote: > I can't find the mail now, but I remember that months ago the Mercurial > migration schedule was mid-december. I wonder if there is any update. I'm still aiming for that date. I've had some problems getting the test repository together. It's almost done, but I'm on holiday in Boston and NYC this week, so I don't have much time to spend on it. The delay shouldn't be much more than a week, and we'll just compress the testing period such that the migration date should still be about the same, release schedules willing. Georg, if you have any further questions, mail is better than IRC while I'm here. Cheers, Dirkjan ___ 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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)
On Sun, Nov 7, 2010 at 13:15, Dirkjan Ochtman wrote: > Yeah, Martin has things for buildbot worked out. Notes about this are > in the hg.python.org/pymigr repository. I meant Georg here, of course. Sorry, Georg! Cheers, Dirkjan ___ 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] Snakebite, buildbot and low hanging fruit -- feedback wanted! (Was Re: SSH access against buildbot boxes)
On Sun, Nov 7, 2010 at 12:24, Trent Nelson wrote: > Titus, for example, alluded to some nifty way for a committer to push his > local hg branch/changes somewhere, such that it would kick off builds on > multiple platforms in the same sorta' vein as point 2, but able to leverage > cloud resources like Amazon's EC2, not just Snakebite hardware. Mozilla has something called the "try server", where people push changes like to any normal repositories, but the result is that it runs all the test suites they have. This lets people painlessly test stuff on all platforms before actually pushing it to one of the main repositories. On Sun, Nov 7, 2010 at 12:50, Nick Coghlan wrote: > With the switch to hg.python.org imminent, it may be better to focus > on Hg for that part (unless you have other projects in mind that also > use SVN). I believe Martin and/or Dirkjan have worked out the > equivalent triggers and build commands needed to switch the buildbot > fleet from svn to hg, but I'm not entirely certain about that one. Yeah, Martin has things for buildbot worked out. Notes about this are in the hg.python.org/pymigr repository. Cheers, Dirkjan ___ 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] Regular scheduled releases
On Sat, Oct 30, 2010 at 14:09, "Martin v. Löwis" wrote: > I don't feel like producing a complete list of build steps; the entire > process takes about four hours. So is most of this scripted, or is there just a process in your head? > The steps that are difficult to automate are: > - code signing > - testing the resulting installer > - uploading Why are those steps difficult to automate? I'd think that uploading is just some ftp commands. Signing might be a thing because you don't want the keys distributed. Testing the resulting installer could probably be automated in part, and people could still download the nightlies to do more testing. > However, in a significant number of releases, some of the build steps > failed, so it requires some investigation to find the source of the > problem. Well, sure, but if we do continuous builds we find failures like that sooner. Cheers, Dirkjan ___ 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] Regular scheduled releases (was: Continuing 2.x)
On Sat, Oct 30, 2010 at 05:22, Nick Coghlan wrote: > Ultimately, the frequency of releases comes down to the burden on the > release manager and the folks that build the binary installers. Any > given RM is usually only responsible for one or two branches, but the > same two people (Martin and Ronald) typically build the Windows and > Mac OS X binaries for all of them. So if you add 2.6 and 3.1 together, > as well as the releases for 2.7 and 3.2 development, I think you'll > find releases happening a lot more often than an average of 1 every 4 > months. Right, the effort of those people is obviously the limiting factor here. Automating builds sounds like a good step forward. What are the sticky bits here? Martin, Ronald, how much of the process is not automated, and why is automating hard? Cheers, Dirkjan ___ 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] Regular scheduled releases (was: Continuing 2.x)
On Fri, Oct 29, 2010 at 21:54, Barry Warsaw wrote: > Another quick thought. What would people think about regular timed releases > if python 2.7? This is probably more a question for Benjamin but doing > sonmight provide better predictability and "customer service" to our users. I > might like to see monthly releases but even quarterly would probably be > useful. Doing timed releases might also incentivize folks to fix more > outstanding 2.7 bugs. I would really like to see a more regular and frequent release schedule. Most of my experience with this is with Mercurial, where we have a time-based schedule with a feature release every four months and a bugfix release at least every month (usually at the first of each month) and more often if we have bad regressions. It's nice because (a) release are practiced more and therefore become easier to do, (b) regressions can be fixed in a shorter timeframe. A predictable schedule is also just nice for all parties involved. In Gentoo, we actually started taking backports from the maintenance branches to fix issues (regressions) in our packages, but didn't work out so well. Obviously a random snapshot from SVN (even from a stable branch) isn't exercised as well as an actual release, so we ended up having some issues due to that. Also releasing packages with a version number that doesn't fully correspond to the tarball is less than ideal (we mitigated this somewhat by adding a date tag to the packages, but still). Here are the bugfix releases from the 2.6 branch: 2.6.1: 64 days 2.6.2: 131 days 2.6.3: 174 days 2.6.4: 23 days (critical regressions) 2.6.5: 145 days 2.6.6: 158 days That's an average of 4 (if you include .4) or 4.5 months (PEP 6 specifies 6 months, but some of the parts seem outdated). I think releasing each month might be a bit ambitious, but it would be great to drive down the release interval towards 2-3 months instead of 4-5. Cheers, Dirkjan ___ 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] Continuing 2.x
On Thu, Oct 28, 2010 at 08:48, Georg Brandl wrote: > I believe we'll eventually have the ability to create user repos as well, so > that Kristjan can simply put his branch into one of these and still have it > on hg.python.org. +1. Cheers, Dirkjan ___ 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] 3.1.3 and 2.7.1 release schedule
On Fri, Oct 22, 2010 at 11:06, Georg Brandl wrote: > If everything goes as planned, there won't be many commits between RC2 and > final, so it should be fine. The svn repos won't be removed anyway, so > making a release from them is still possible. Okay, but accepting commits in both SVN and hg at the same time is potentially messy. > (Side question: do we want to move the svn repos to a slightly different > URL so that people tracking the repo know something's happened?) I would be in favor of that, yes. Cheers, Dirkjan ___ 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] 3.1.3 and 2.7.1 release schedule
On Fri, Oct 22, 2010 at 00:57, Benjamin Peterson wrote: > In the interest of getting 3.1.3 and 2.7.1 out by next year, here's a > tentative release schedule: > > November 13th - RC1 > November 27th - RC2 > December 11th - Final The last one might clash with the hg migration a bit, do we need to worry about that? Or did you purposely pick the day before the planned hg migration? Cheers, Dirkjan ___ 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] hg migration schedule
Okay, we're getting somewhere here. I've been conferring with Georg on when we can do the conversion. He's done some testing with the buildbot setup, which seems to be mostly done. He also completed preliminary ports of the hooks used in the SVN repository. He managed to convince me that we're at a point where it would be good to post some kind of schedule, so here we go. 2010-11-13: availability of a test repo I'm working towards finally having a test repository that's close to what we'll have for the final repository. I hope to have it done sooner than by Nov 13, so it seems like a fairly realistic date. I'm not promising we'll also have docs done by then, but good documentation will be my focus as soon as I'm done with the test repository. I should also mention that I'll be visiting the US east cost (Boston and NYC) from Nov 13 to Nov 21, so I probably won't be spending much time on this that week. 2010-12-12: final conversion (tentative) Georg would really like the conversion to be done by the end of the year, and it seems that this is within reach. The aim here is not to disturb the 3.2 release process too much, of course, while still giving Georg more powerful tools to manage what's left of the release process. We're currently tracking progress in a todo.txt file in the pymigr repo [1] (and in the #python-dev IRC channel), so if you want to help out, you're more than welcome! We're also going to need at least one more big fight about workflow/organizational issues, but I'd like to hold off on that until after we have a test repo that can actually demonstrate the issues that are relevant to that discussion. Cheers, Dirkjan [1] http://hg.python.org/pymigr/file/tip/todo.txt ___ 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 15:22, Tarek Ziadé wrote: > Mmm.. setup.py is gone in D2, and setup.py will be the marker of d1. So, sorry for backing up to this, but isn't it true that many projects do custom stuff in their setup.py that they wouldn't be able to do in setup.cfg? Is the goal really to make that impossible/unnecessary? In Mercurial, for example, we have a fairly large setup.py that helps us deal with many kinds of issues: incomplete Python installations on different platforms, adding packages depending on the platform, do custom stuff to compile gettext files, etc... Cheers, Dirkjan ___ 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] Distutils2 scripts
2010/10/8 Fred Drake : > Georg: >> What happened to "python setup.py action"? Or is this a step towards >> not requiring setup.py at all? > > I'm in favor of add a top-level setup module that can be invoked using > "python -m setup ...". There will be three cases: > > - d2 projects without a setup.py, where this will invoke the module from > the standard library, > > - d2 projects with a setup.py, where the local setup.py will be invoked, > and > > - d1 projects, which always have a setup.py, which will be invoked. > > This would provide the most consistent story for package users, where the > only command they'll need to remember (for Python versions with the setup > module) will be > > python -m setup ... That seems like a fairly elegant solution. Cheers, Dirkjan ___ 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] Distutils2 scripts
On Fri, Oct 8, 2010 at 09:05, Tarek Ziadé wrote: > The feedback I received for this is pretty clear: people want a single > script that can be called directly. e.g. > > $ distutils2 depgraph > $ distutils2 install > $ distutils2 run command > > Fair enough, I can add that script in the project and get it installed > when people install the project. It doesn't seem very nice to have a version in the script. Can we just call it distutils? Or py-dist? paint-it-some-other-color-ly yours, Dirkjan ___ 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] opinions on issue2142 ('\ No newline at end of file' to difflib.unified_diff)?
On Thu, Oct 7, 2010 at 00:53, Trent Mick wrote: > 1. Change `difflib.unified_diff` to emit: > > ['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n', > '-three\n', '\ No newline at end of file', '+trois\n', '\ No newline > at end of file'] > > instead of: > > ['--- \n', '+++ \n', '@@ -1,3 +1,3 @@\n', ' one\n', ' two\n', > '-three', '+trois'] > > for this case. > > > 2. Add a `add_end_of_file_newline_markers_to_make_patch_happy` keyword > arg (probably with a different name:) to `difflib.unified_diff` to do > this additional handling. The reason is to not surprise existing code > that would be surprised with those "\No newline at end of file" > entries. > > 3. Not touch `difflib.unified_diff` and instead update > http://docs.python.org/library/difflib.html#difflib-interface > documentation to discuss the issue and show how users of unified_diff > should handle this case themselves. Mark (in the issue) argues that there is no specification for diffs, and that this is thus a feature, not a bug. On the other hand, in Mercurial we've maintained the idea that diffs are specified by whatever (GNU) patch(1) accepts. So I would support treating this as a bug, not just a feature. As such, I think 3.2 should emit the extra line by default and add a keyword argument to make it easy to revert to the old behavior (and add docs to 2.7, 3.1 and 3.2 about the issue!). Cheers, Dirkjan ___ 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] Who wants to donate an AMD64 Linux build slave?
On Tue, Oct 5, 2010 at 17:06, "Martin v. Löwis" wrote: >> I can probably run a build slave on one of my boxes (Gentoo, Athlon 64 >> x2). Where are the setup docs? > > http://wiki.python.org/moin/BuildBot Cool, can you get me username/passwd? Cheers, Dirkjan ___ 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
