Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3
2012/2/27 Barry Warsaw > On Feb 26, 2012, at 05:44 PM, Brett Cannon wrote: > > >On Sat, Feb 25, 2012 at 22:13, Guido van Rossum wrote: > > > >> If this can encourage more projects to support Python 3 (even if it's > >> only 3.3 and later) and hence improve adoption of Python 3, I'm all > >> for it. > >> > >> > >+1 from me for the same reasons. > > Just to be clear, I'm solidly +1 on anything we can do to increase the > pace of > Python 3 migration. > +1 I think this is a great proposal that has the potential to remove one of the (for me at least, _the_) main obstacles to writing code compatible with both 2.7 and 3.x. -- /f I reject your reality and substitute my own. http://blaag.haard.se ___ 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] New-style formatting in the logging module (was Re: cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats)
Nick Coghlan gmail.com> writes:
> It's half the puzzle (since composing the event fields into the actual
> log output is a logger action, you know the style when you supply the
> format string). The other half is that logging's lazy formatting
> currently only supporting printf-style format strings - to use brace
> formatting you currently have to preformat the messages, so you incur
> the formatting cost even if the message gets filtered out by the
> logging configuration.
That isn't necessarily true. Lazy formatting can work for {} and $ formatting
types, not just %-formatting: see
http://plumberjack.blogspot.com/2010/10/supporting-alternative-formatting.html
Composing the event fields into the message is done by the LogRecord, which
calls str() on the object passed as the format string to get the actual format
string. This allows you to use any of the standard formatting schemes and still
take advantage of lazy formatting, as outlined in the above post.
Although style support for Formatters is new, that's really for merging the
logging event message into the overall log output (with time, severity etc.) -
the support for having your own way of formatting the event message has always
been there, even before str.format :-)
The Formatter style functionality is also available for 2.x through a separate
logutils project which I maintain and which contains features which were added
to logging in 3.2 such as QueueHandler/QueueListener:
http://pypi.python.org/pypi/logutils/
I will add a section in the logging cookbook about support for alternative
formatting styles. I thought I already had, but on inspection, it appears not to
be the case.
Regards,
Vinay Sajip
___
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 414 - Unicode Literals for Python 3
Am 26.02.2012 07:06, schrieb Nick Coghlan: > On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum wrote: >> A small quibble: I'd like to see a benchmark of a 'u' function implemented >> in C. > > Even if it was quite fast, I don't think such a function would bring > the same benefits as restoring support for u'' literals. You claim that, but your argument doesn't actually support that claim (or I fail to see the argument). > > Using myself as an example, my work projects (such as PulpDist [1]) > are currently written to target Python 2.6, since that's the system > Python on RHEL 6. As a web application, PulpDist has unicode literals > *everywhere*, but (as Armin pointed out to me), turning on "from > __future__ import unicode_literals" in every file would be incorrect, Right. So you shouldn't use the __future__ import, but the u() function. > IIRC, I've previously opposed the restoration of unicode literals as a > retrograde step. Looking at the implications for the future migration > of PulpDist has changed my mind. Did you try to follow the path of the u() function? Regards, Martin ___ 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 414
> Much of the software I work on is Python 3 compatible, but it's still > used primarily on Python 2. Because most people still care primarily > about Python 2, and most don't have a lot of Python 3 experience, it's > extremely common to see folks submitting patches with u'' literals in > them. These can be easily fixed, right? Regards, Martin ___ 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 414 - Unicode Literals for Python 3
>> There are no significant overhead to use converters. > That's because what you're benchmarking here more than anything is the > overhead of eval() :-) See the benchmark linked in the PEP for one that > measures the actual performance of the string literal / wrapper. There are a few other unproven performance claims in the PEP. Can you kindly provide the benchmarks you have been using? In particular, I'm interested in the claim " In many cases 2to3 runs one or two orders of magnitude slower than the testsuite for the library or application it's testing." Regards, Martin ___ 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 414 - Unicode Literals for Python 3
Am 27.02.2012 00:07, schrieb Barry Warsaw: > On Feb 26, 2012, at 05:44 PM, Brett Cannon wrote: > >> On Sat, Feb 25, 2012 at 22:13, Guido van Rossum wrote: >> >>> If this can encourage more projects to support Python 3 (even if it's >>> only 3.3 and later) and hence improve adoption of Python 3, I'm all >>> for it. >>> >>> >> +1 from me for the same reasons. > > Just to be clear, I'm solidly +1 on anything we can do to increase the pace of > Python 3 migration. I find this rationale a bit sad: it's not that there is any (IMO) good technical reason for the feature - only that people "hate" the many available alternatives for some reason. But then, practicality beats purity, so be it. Regards, Martin ___ 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] Marking packaging-related PEPs as Finished after fixing some bugs in them
Hello, The three packaging-related PEPs that were written by the distutils SIG and approved two years ago are still marked as Accepted, not Finished: SA 345 Metadata for Python Software Packages 1.2 Jones SA 376 Database of Installed Python Distributions Ziadé SA 386 Changing the version comparison module in Distutils Ziadé They’re all implemented in packaging/distutils2. Sadly, all of them have rather serious issues, so I wanted to ask what the process should be to solve the problems and mark the PEPs final. In PEP 345, legal values for project names are not defined, so for example “Foo (>=0.5)” could legally be a project named Foo without version predicate, or a project named “Foo (>=0.5)”. I don’t have a solution to propose, as I did not run a poll or check existing projects. Second, the Provides-Dist allows values like “Name (<= version)”, which does not make sense: it should allow only unversioned names and names with one version (without operators). Finally, some of the new metadata fields are also misnamed, namely the ones ending in -Dist like Requires-Dist, whose value is a release (i.e. a name + optional version specifier), not a distribution (i.e. a specific archive or installer for a release), and therefore should be Requires-Release or something prettier. (Remember that it cannot be just Requires, which is taken by PEP 314, contains module names instead of project names, and is not used by anyone TTBOMK.) packaging.database, which implements PEP 376, has a few known bugs; I don’t know if that should prevent the PEP from being marked Finished. It could be that finishing the implementation shows issues in the PEP, like for the other two. In PEP 386, the rule that versions using an 'rc' marker should sort after 'c' is buggy: I don’t think anyone will disagree that 1.0rc1 == 1.0c1 and 1.0rc1 < 1.0c2. The 'rc' marker was added by Tarek shortly before the PEP was accepted (see http://mail.python.org/pipermail/python-dev/2010-January/097041.html), and was not discussed. My preferred solution would be to accept 'rc' when parsing but then always use 'c' internally and in all output (file names, METADATA file, etc.). If it is judged important that projects be able to use 'rc' and see it in output, then I’ll have to add special cases in __eq__ and __hash__ methods, which is feasible if inelegant. (Issues found by Josip Djolonga, Alexis Métaireau and I.) Cheers ___ 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 414 - Unicode Literals for Python 3
Il 25 febbraio 2012 21:23, Armin Ronacher ha scritto: > Hi, > > I just uploaded PEP 414 which proposes am optional 'u' prefix for string > literals for Python 3. > > You can read the PEP online: http://www.python.org/dev/peps/pep-0414/ > > This is a followup to the discussion about this topic here on the > mailinglist and on twitter/IRC over the last few weeks. > > > Regards, > Armin If the main point of this proposal is avoiding an explicit 2to3 run on account of 2to3 being too slow then I'm -1. That should be fixed at 2to3 level, not at python syntax level. A common strategy to distribute code able to run on both python 2 and python 3 is using the following hack in setup.py: http://docs.python.org/dev/howto/pyporting.html#during-installation That's what I used in psutil and it works just fine. Also, I believe it's the *right* strategy as it lets you freely write python 2 code and avoid using ugly hacks such as "sys.exc_info()[1]" and "if PY3: ..." all around the place. 2to3 might be slow but introducing workarounds encouraging not to use it is only going to cause a proliferation of ugly and hackish code in the python ecosystem. Now, psutil is a relatively small project and the 2to3 conversion doesn't take much time. Having users "unawarely" run 2to3 at installation time is an acceptable burden in terms of speed. That's going to be different on larger code bases such as Twisted's. One way to fix that might be making 2to3 generate and rely on a "2to3.diff" file containing all the differences. That would be generated the first time "python setup.py build/install" is run and then partially re-calculated every time a file is modified. Third-party library vendors can include 2to3.diff as part of the tarball they distribute so that the end user won't experience any slow down deriving from the 2to3 conversion. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ http://code.google.com/p/pysendfile/ ___ 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] Marking packaging-related PEPs as Finished after fixing some bugs in them
On Mon, Feb 27, 2012 at 12:40, Éric Araujo wrote: > In PEP 386, the rule that versions using an 'rc' marker should sort > after 'c' is buggy: I don’t think anyone will disagree that 1.0rc1 == > 1.0c1 and 1.0rc1 < 1.0c2. The 'rc' marker was added by Tarek shortly > before the PEP was accepted (see > http://mail.python.org/pipermail/python-dev/2010-January/097041.html), > and was not discussed. My preferred solution would be to accept 'rc' > when parsing but then always use 'c' internally and in all output (file > names, METADATA file, etc.). If it is judged important that projects be > able to use 'rc' and see it in output, then I’ll have to add special > cases in __eq__ and __hash__ methods, which is feasible if inelegant. I also didn't like the fact that 'rc' > 'c'. The change you are proposing will also make the code change far simpler. Note that the code (the one in the main VCS), sort of assumed that 'rc'=='c', but is missing the assignment, and therefore broken. ___ 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] Marking packaging-related PEPs as Finished after fixing some bugs in them
On Mon, 27 Feb 2012 11:40:08 +0100 Éric Araujo wrote: > > In PEP 386, the rule that versions using an 'rc' marker should sort > after 'c' is buggy: I don’t think anyone will disagree that 1.0rc1 == > 1.0c1 and 1.0rc1 < 1.0c2. The 'rc' marker was added by Tarek shortly > before the PEP was accepted (see > http://mail.python.org/pipermail/python-dev/2010-January/097041.html), > and was not discussed. My preferred solution would be to accept 'rc' > when parsing but then always use 'c' internally and in all output (file > names, METADATA file, etc.). If it is judged important that projects be > able to use 'rc' and see it in output, then I’ll have to add special > cases in __eq__ and __hash__ methods, which is feasible if inelegant. 'rc' makes sense to most people while 'c' is generally unheard of. Regards Antoine. > > (Issues found by Josip Djolonga, Alexis Métaireau and I.) > > Cheers > ___ > 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/python-python-dev%40m.gmane.org ___ 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 414 - Unicode Literals for Python 3
On Mon, Feb 27, 2012 at 9:34 PM, Giampaolo Rodolà wrote: > If the main point of this proposal is avoiding an explicit 2to3 run on > account of 2to3 being too slow then I'm -1. No, the main point is that adding a compile step to the Python development process sucks. The slow speed of 2to3 is one factor, but single source is just far, far, easier to maintain than continually running 2to3 to get a working Python 3 version. When we have the maintainers of major web frameworks and libraries telling us that this is a painful aspect for their ports (and, subsequently, the ports of their users), it would be irresponsible of us to ignore their feedback. Sure, some early adopters are happy with the 2to3 process, that's not in dispute. However, many developers are not, and (just as relevant) many folks that haven't started their ports yet have highlighted it as one of the aspects that bothers them. Is restoring support for unicode literals a small retrograde step that partially undoes the language cleanup that occurred in 3.0? Yes, it is. However, it really does significantly increase the amount of 2.x code that will *just run* on Python 3 (or will run with minor tweaks). I can live with that - as MvL said, this is a classic case of practicality beating purity. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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 (3.2): Updated logging cookbook with info on alternative format styles.
On Mon, Feb 27, 2012 at 9:04 PM, vinay.sajip wrote:
> +There is, however, a way that you can use {}- and $- formatting to construct
> +your individual log messages. Recall that for a message you can use an
> +arbitrary object as a message format string, and that the logging package
> will
> +call ``str()`` on that object to get the actual format string. Consider the
> +following two classes::
> +
> + class BraceMessage(object):
> + def __init__(self, fmt, *args, **kwargs):
> + self.fmt = fmt
> + self.args = args
> + self.kwargs = kwargs
> +
> + def __str__(self):
> + return self.fmt.format(*self.args, **self.kwargs)
> +
> + class DollarMessage(object):
> + def __init__(self, fmt, **kwargs):
> + self.fmt = fmt
> + self.kwargs = kwargs
> +
> + def __str__(self):
> + from string import Template
> + return Template(self.fmt).substitute(**self.kwargs)
> +
> +Either of these can be used in place of a format string, to allow {}- or
> +$-formatting to be used to build the actual "message" part which appears in
> the
> +formatted log output in place of "%(message)s" or "{message}" or "$message".
> +It's a little unwieldy to use the class names whenever you want to log
> +something, but it's quite palatable if you use an alias such as __ (double
> +underscore – not to be confused with _, the single underscore used as a
> +synonym/alias for :func:`gettext.gettext` or its brethren).
This is the part I was thinking might be simplified by allowing a
"style" parameter to be passed to getLogger().
Consider StrFormatLogger and StringTemplateLogger classes that were
just wrappers around an ordinary Logger instance, and made the
relevant conversions to StrFormatMessage or StringTemplateMessage on
the caller's behalf.
Then (assuming the current getLogger() is available as _getLogger()),
you could just do something like:
_LOGGER_STYLES = {
"%": lambda x: x,
"{": StrFormatLogger,
"$": StringTemplateLogger,
}
def getLogger(name, style='%'):
if style not in _STYLES:
raise ValueError('Style must be one of: %s' %
','.join(_LOGGER_STYLES.keys()))
return _LOGGER_STYLES[style](_getLogger())
Since each module should generally be doing its own getLogger() call
(or else should be documenting that it accepts an ordinary logger
instance as a parameter), it seems like this would allow fairly clean
use of the alternate styles without complicating each individual
logging operation.
(The xyzStyle approach used by formatters here won't work, since we
want different modules to be able to use different formatting styles.
However, ordinary inheritance should allow StrFormatLogger and
StringTemplateLogger to share most of their implementation)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
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] Marking packaging-related PEPs as Finished after fixing some bugs in them
On Feb 27, 2012, at 11:40 AM, Éric Araujo wrote: > They’re all implemented in packaging/distutils2. Sadly, all of them >have rather serious issues, so I wanted to ask what the process should >be to solve the problems and mark the PEPs final. From a process point of view, I'd say you should fix the PEP issues you know about, and publish new versions, updating the Post-History field. These PEPs were written before the BDFOP/Czar policy came about, so why not see if you can find someone acceptable to Guido (or maybe suggested by him) to pronounce on the PEPs. Then, if the BDFOP agrees you can mark them Final, since I think they almost are, effectively. Marking them Final doesn't mean they can't be updated if you find some issues with them later. You and the BDFOP might decide to defer Final acceptance until the bugs in the implementations are fixed though. Cheers, -Barry ___ 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 414 - Unicode Literals for Python 3
On Feb 27, 2012, at 12:34 PM, Giampaolo Rodolà wrote: >Il 25 febbraio 2012 21:23, Armin Ronacher >If the main point of this proposal is avoiding an explicit 2to3 run on >account of 2to3 being too slow then I'm -1. 2to3's speed isn't the only problem with the tool, although it's a big one. It also doesn't always work, and it makes packaging libraries dependent on it more difficult. As for the "working" part, I forget the details, but let's say you have a test suite in your package. If you run `python setup.py test` in a Python 2 world, then `python3 setup.py test` may fail to build properly. IIRC this was due to some confusion that 2to3 had. I've no doubt that these things can be fixed, but why? I'd much rather see the effort put into allowing us to write Python 3 code natively, with some accommodations for Python 2 from a single code base for the last couple of years that that will still be necessary . Cheers, -Barry ___ 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 414 - Unicode Literals for Python 3
On Feb 27, 2012, at 11:21 AM, Martin v. Löwis wrote: >I find this rationale a bit sad: it's not that there is any (IMO) good >technical reason for the feature - only that people "hate" the many >available alternatives for some reason. It makes me sad too, and as I've said, I personally have no problem with the existing solutions. They work just fine for me. But I also consistently hear from folks doing web frameworks that there's a big missing piece in the Python 3 story for them. Maybe restoring u-prefix solves their problem, or maybe there's another better solution out there. I don't do a lot of web development these days so I can't say. -Barry signature.asc Description: PGP signature ___ 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 414 - Unicode Literals for Python 3
On Mon, 27 Feb 2012 11:21:16 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
wrote:
> I find this rationale a bit sad: it's not that there is any (IMO) good
> technical reason for the feature - only that people "hate" the many
> available alternatives for some reason.
>
> But then, practicality beats purity, so be it.
Agreed on both counts (but only reluctantly on the second :)
The PEP does not currently contain a discussion of the unicode_literals +
str() alternative and why that is not considered acceptable. That should
be added (and I'm very curious why it isn't acceptable, it seems very
elegant to me).
In fact, I'd like to see the PEP contain a bullet list of alternatives
with a discussion of why each is unacceptable or insufficient. The text
as organized now is hard to follow for that purpose.
Other comments:
I disagree that "it is clear that 2to3 as a tool is insufficient" and
that *therefore* people are attempting to use unified source. I think
the truth is that people just prefer the unified source approach,
because that is more Pythonic.
I also strongly disagree with the statement that unicode_literals is
doing more harm that good. Many people are using it very successfully.
In *certain contexts* (WSGI) it may be problematic, but that doesn't
mean it was a bad idea or that it shouldn't be used (given that a
project uses it consistently, as noted previously in this thread).
As noted above, the native string type *is* available with
unicode_literals, it is spelled "str('somestring').
I don't understand the "Who Benefits?" section at all. For example, I
think you'll agree I'm experienced working with email issues, and I don't
understand how this proposal would help at all in dealing with email.
The PEP would be strengthened by providing specific examples of the
claims made in this section.
I am -0 on this proposal. I will bow to the experience of those actually
trying to port and support web code, which I am not doing myself.
But I'd like to see the PEP improved so that the proposal is as strong
as possible.
--David
___
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 414 - Unicode Literals for Python 3
Barry Warsaw python.org> writes: > As for the "working" part, I forget the details, but let's say you have a test > suite in your package. If you run `python setup.py test` in a Python 2 world, > then `python3 setup.py test` may fail to build properly. IIRC this was due to > some confusion that 2to3 had. > There are other things, too, which make 2to3 a good advisory tool rather than a fully automated solution. 2to3 does a pretty good job of solving a difficult problem, but there are some things it just won't be able to do. For example, it assumes that certain method names belong to dictionaries and wraps their result with a list() because 3.x produces iterators where 2.x produces lists. This has caused problems in practice, e.g. with Django where IIRC calls to the values() method of querysets were wrapped with list(), when it was wrong to do so. Regards, Vinay Sajip ___ 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 414 - Unicode Literals for Python 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/2012 06:34 AM, Giampaolo Rodolà wrote: > Il 25 febbraio 2012 21:23, Armin Ronacher > ha scritto: >> Hi, >> >> I just uploaded PEP 414 which proposes am optional 'u' prefix for >> string literals for Python 3. >> >> You can read the PEP online: >> http://www.python.org/dev/peps/pep-0414/ >> >> This is a followup to the discussion about this topic here on the >> mailinglist and on twitter/IRC over the last few weeks. >> >> >> Regards, Armin > > If the main point of this proposal is avoiding an explicit 2to3 run > on account of 2to3 being too slow then I'm -1. The main point is that 2to3 as a strategy for "straddling" python2 and python3 is a showstopper for folks who actually need to straddle (as opposed to one-time conversion): - - 2to3 erformance on large projects sucks. - - 2to3 introduces oddities in testing, coverage, etc. - - 2to3 creates problems with stack traces / bug reports from Py3k users. There are a *lot* of folks who have abandoned 2to3 in favor of "single codebase": the PEP addresses one of the last remaining issues to making such codebases clean and easy to maintain (the sys.exec_info hack is not needed in Python >= 2.6). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design" http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9Lmj4ACgkQ+gerLs4ltQ5wBgCfXWUe81vnQh5ptKpGhqLTOL5L oUgAnRrgEUFIq85rgGU6Ky3kN+KzZaqV =CNVl -END PGP SIGNATURE- ___ 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 414
Hi, On 2/27/12 1:55 AM, Terry Reedy wrote: > I presume such a hook would simply remove 'u' prefixes and would run > *much* faster than 2to3. If such a hook is satisfactory for 3.2, why > would it not be satisfactory for 3.3? Agile development and unittests. An installation hook means that you need to install the package before running the tests. Which is fine for CI but horrible during development. "python3 run-tests.py" beats "make venv; install library; run testsuite" anytime in terms of development speed. Regards, Armin ___ 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 414 - Unicode Literals for Python 3
Hi, On 2/27/12 10:17 AM, "Martin v. Löwis" wrote: > There are a few other unproven performance claims in the PEP. Can you > kindly provide the benchmarks you have been using? In particular, I'm > interested in the claim " In many cases 2to3 runs one or two orders of > magnitude slower than the testsuite for the library or application it's > testing." The benchmarks used are linked in the PEP. Regards, Armin ___ 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 415: Implementing PEP 409 differently
2012/2/26 Nick Coghlan : > Thanks for writing that up. I'd be amenable if the PEP was clearly > updated to say that ``raise exc from cause`` would change from being > syntactic sugar for ``_hidden = exc; _hidden.__cause__ = cause; raise > exc`` (as it is now) to ``_hidden = exc; _hidden.__cause__ = cause; > _hidden.__suppress_context__ = True; raise exc``. The patch should > then be implemented accordingly (including appropriate updates to the > language reference). I add the following lines to the PEP: To summarize, ``raise exc from cause`` will be equivalent to:: exc.__cause__ = cause exc.__suppress_context__ = cause is None raise exc -- Regards, Benjamin ___ 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 414
On Mon, Feb 27, 2012 at 5:44 PM, Armin Ronacher wrote: > Agile development and unittests. An installation hook means that you > need to install the package before running the tests. Which is fine for > CI but horrible during development. "python3 run-tests.py" beats "make > venv; install library; run testsuite" anytime in terms of development speed. "python3 setup.py test" works already with 2to3 (it builds the code and runs the tests under build/). It is however slow and it can be a bit annoying to have to debug things by looking at the generated code under build/lib.linux-i686-3.2/ (or similar). ___ 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 414 - Unicode Literals for Python 3
Zitat von Armin Ronacher : Hi, On 2/27/12 10:17 AM, "Martin v. Löwis" wrote: There are a few other unproven performance claims in the PEP. Can you kindly provide the benchmarks you have been using? In particular, I'm interested in the claim " In many cases 2to3 runs one or two orders of magnitude slower than the testsuite for the library or application it's testing." The benchmarks used are linked in the PEP. Maybe I'm missing something, but there doesn't seem to be a benchmark that measures the 2to3 performance, supporting the claim that it runs "two orders of magnitude" slower (which I'd interpret as a factor of 100). If the claim actually cannot be supported, please remove it from the PEP. Regards, Martin ___ 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 414 - Unicode Literals for Python 3
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum wrote:
A small quibble: I'd like to see a benchmark of a 'u' function implemented in C.
Even if it was quite fast, I don't think such a function would bring
the same benefits as restoring support for u'' literals.
You claim that, but your argument doesn't actually support that claim
(or I fail to see the argument).
Python 2.6 code:
this = u'that'
Python 3.3 code:
this = u('that')
Not source compatible, not elegant. (Even though 2to3 could make this
fix, it's still kinda ugly.)
~Ethan~
___
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 414 - Unicode Literals for Python 3
On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman wrote:
> Martin v. Löwis wrote:
> > Am 26.02.2012 07:06, schrieb Nick Coghlan:
> >> On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum wrote:
> >>> A small quibble: I'd like to see a benchmark of a 'u' function
> >>> implemented in C.
> >> Even if it was quite fast, I don't think such a function would bring
> >> the same benefits as restoring support for u'' literals.
> >
> > You claim that, but your argument doesn't actually support that claim
> > (or I fail to see the argument).
>
> Python 2.6 code:
> this = u'that'
>
> Python 3.3 code:
> this = u('that')
>
> Not source compatible, not elegant. (Even though 2to3 could make this
> fix, it's still kinda ugly.)
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
--David
___
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 414 - Unicode Literals for Python 3
On Sun, 26 Feb 2012 12:42:53 +
Armin Ronacher wrote:
> Hi,
>
> On 2/26/12 12:35 PM, Serhiy Storchaka wrote:
> > Some microbenchmarks:
> >
> > $ python -m timeit -n 1 -r 100 -s "x = 123" "'foobarbaz_%d' % x"
> > 1 loops, best of 100: 1.24 usec per loop
> > $ python -m timeit -n 1 -r 100 -s "x = 123" "str('foobarbaz_%d') % x"
> > 1 loops, best of 100: 1.59 usec per loop
> > $ python -m timeit -n 1 -r 100 -s "x = 123" "str(u'foobarbaz_%d') % x"
> > 1 loops, best of 100: 1.58 usec per loop
> > $ python -m timeit -n 1 -r 100 -s "x = 123; n = lambda s: s"
> "n('foobarbaz_%d') % x"
> > 1 loops, best of 100: 1.41 usec per loop
> > $ python -m timeit -n 1 -r 100 -s "x = 123; s = 'foobarbaz_%d'" "s
> % x"
> > 1 loops, best of 100: 1.22 usec per loop
> >
> > There are no significant overhead to use converters.
> That's because what you're benchmarking here more than anything is the
> overhead of eval() :-) See the benchmark linked in the PEP for one that
> measures the actual performance of the string literal / wrapper.
Could you update your benchmarks with the caching version of u()?
Thanks
Antoine.
___
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 414 - Unicode Literals for Python 3
On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
> On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman wrote:
> > Martin v. Löwis wrote:
> > > Am 26.02.2012 07:06, schrieb Nick Coghlan:
> > >> On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum
> > >> wrote:
> > >>> A small quibble: I'd like to see a benchmark of a 'u' function
> > >>> implemented in C.
> > >> Even if it was quite fast, I don't think such a function would bring
> > >> the same benefits as restoring support for u'' literals.
> > >
> > > You claim that, but your argument doesn't actually support that claim
> > > (or I fail to see the argument).
> >
> > Python 2.6 code:
> > this = u'that'
> >
> > Python 3.3 code:
> > this = u('that')
> >
> > Not source compatible, not elegant. (Even though 2to3 could make this
> > fix, it's still kinda ugly.)
>
> Eh? The 2.6 version would also be u('that'). That's the whole point
> of the idiom. You'll need a better counter argument than that.
The best argument is that there already exists tons and tons of Python 2
code that already does:
u'that'
Needing to change it to:
u('that')
1) Requires effort on the part of a from-Python-2-porter to service
the aesthetic and populist goal of not having an explicit
but redundant-under-Py3 literal syntax that says "this is text".
2) Won't atually meet the aesthetic goal, as
it's uglier and slower under *both* Python 2 and Python 3.
So the populist argument remains.. "it's too confusing for people who
learn Python 3 as a new language to have a redundant syntax". But we've
had such a syntax in Python 2 for years with b'', and, as mentioned by
Armin's PEP single-quoted vs. triple-quoted strings forever.
I just don't understand the pushback here at all. This is such a
nobrainer.
- C
___
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 414 - Unicode Literals for Python 3
On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonough wrote:
> The best argument is that there already exists tons and tons of Python 2
> code that already does:
>
> u'that'
+1
> Needing to change it to:
>
> u('that')
>
> 1) Requires effort on the part of a from-Python-2-porter to service
> the aesthetic and populist goal of not having an explicit
> but redundant-under-Py3 literal syntax that says "this is text".
>
> 2) Won't actually meet the aesthetic goal, as
> it's uglier and slower under *both* Python 2 and Python 3.
>
> So the populist argument remains.. "it's too confusing for people who
> learn Python 3 as a new language to have a redundant syntax". But we've
> had such a syntax in Python 2 for years with b'', and, as mentioned by
> Armin's PEP single-quoted vs. triple-quoted strings forever.
>
> I just don't understand the pushback here at all. This is such a
> nobrainer.
I agree. Just let's start deprecating it too, so that once Python 2.x
compatibility is no longer relevant we can eventually stop supporting
it (though that may have to wait until Python 4...). We need to send
*some* sort of signal that this is a compatibility hack and that no
new code should use it. Maybe a SilentDeprecationWarning?
--
--Guido van Rossum (python.org/~guido)
___
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 415: Implementing PEP 409 differently
Benjamin Peterson wrote: 2012/2/26 Nick Coghlan : Thanks for writing that up. I'd be amenable if the PEP was clearly updated to say that ``raise exc from cause`` would change from being syntactic sugar for ``_hidden = exc; _hidden.__cause__ = cause; raise exc`` (as it is now) to ``_hidden = exc; _hidden.__cause__ = cause; _hidden.__suppress_context__ = True; raise exc``. The patch should then be implemented accordingly (including appropriate updates to the language reference). I add the following lines to the PEP: To summarize, ``raise exc from cause`` will be equivalent to:: exc.__cause__ = cause exc.__suppress_context__ = cause is None raise exc So exc.__cause__ will be None both before and after `raise Exception from None`? ~Ethan~ ___ 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 414 - Unicode Literals for Python 3
On 2/27/2012 1:01 PM, Chris McDonough wrote:
On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
The best argument is that there already exists tons and tons of Python 2
code that already does:
u'that'
Needing to change it to:
u('that')
1) Requires effort on the part of a from-Python-2-porter to service
the aesthetic and populist goal of not having an explicit
but redundant-under-Py3 literal syntax that says "this is text".
This is a point, though this would be a one-time conversion by a 2to23
converter that would be part of other needed conversions, some by hand.
I presume that most 2.6 code has problems other than u'' when attempting
to run under 3.x.
2) Won't atually meet the aesthetic goal, as
it's uglier and slower under *both* Python 2 and Python 3.
Less relevant. The minor ugliness would be in dual-version code, but not
Python 3 itself.
So the populist argument remains.. "it's too confusing for people who
learn Python 3 as a new language to have a redundant syntax". But we've
had such a syntax in Python 2 for years with b'', and, as mentioned by
Armin's PEP single-quoted vs. triple-quoted strings forever.
I just don't understand the pushback here at all.
For one thing, u'' does not solve the problem for 3.1 and 3.2, while u()
does. 3.2 will be around for years. For one example, it will be in the
April long-term-support release of Ubuntu. For another, PyPy is working
on a 3.2 compatible version to come out and be put into use this year.
> This is such a nobrainer.
I could claim that a solution that also works for 3.1 and 3.2 is a
nobrainer. It depends on how one weighs different factors.
--
Terry Jan Reedy
___
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 414 - Unicode Literals for Python 3
R. David Murray wrote:
On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman wrote:
Martin v. Löwis wrote:
Am 26.02.2012 07:06, schrieb Nick Coghlan:
On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum wrote:
>
A small quibble: I'd like to see a benchmark of a 'u' function implemented in C.
Even if it was quite fast, I don't think such a function would bring
the same benefits as restoring support for u'' literals.
You claim that, but your argument doesn't actually support that claim
(or I fail to see the argument).
>>
Python 2.6 code:
this = u'that'
Python 3.3 code:
this = u('that')
Not source compatible, not elegant. (Even though 2to3 could make this
fix, it's still kinda ugly.)
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
So the idea is to convert the existing 2.6 code to use parenthesis as
well? (I obviously haven't read the PEP -- my apologies.)
Then I primarily object on ergonomic reasons, but I still think it's
kinda ugly. ;)
~Ethan~
___
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] Add a frozendict builtin type
Rationale
=
A frozendict type is a common request from users and there are various
implementations. There are two main Python implementations:
* "blacklist": frozendict inheriting from dict and overriding methods
to raise an exception when trying to modify the frozendict
* "whitelist": frozendict not inheriting from dict and only implement
some dict methods, or implement all dict methods but raise exceptions
when trying to modify the frozendict
The blacklist implementation has a major issue: it is still possible
to call write methods of the dict class (e.g. dict.set(my_frozendict,
key, value)).
The whitelist implementation has an issue: frozendict and dict are not
"compatible", dict is not a subclass of frozendict (and frozendict is
not a subclass of dict).
I propose to add a new frozendict builtin type and make dict type
inherits from it. frozendict would not have methods to modify its
content and values must be immutable.
Constraints
===
* frozendict values must be immutable, as dict keys
* frozendict can be used with the C API of the dict object (e.g.
PyDict_GetItem) but write methods (e.g. PyDict_SetItem) would fail
with a TypeError ("expect dict, got frozendict")
* frozendict.__hash__() has to be determinist
* frozendict has not the following methods: clear, __delitem__, pop,
popitem, setdefault, __setitem__ and update. As tuple/frozenset has
less methods than list/set.
* issubclass(dict, frozendict) is True, whereas
issubclass(frozendict, dict) is False
Implementation
==
* Add an hash field to the PyDictObject structure
* Make dict inherits from frozendict
* frozendict values are checked for immutability property by calling
their __hash__ method, with a fast-path for known immutable types
(int, float, bytes, str, tuple, frozenset)
* frozendict.__hash__ computes hash(frozenset(self.items())) and
caches the result is its private hash attribute
Attached patch is a work-in-progress implementation.
TODO
* Add a frozendict abstract base class to collections?
* frozendict may not overallocate dictionary buckets?
--
Examples of frozendict implementations:
http://bob.pythonmac.org/archives/2005/03/04/frozendict/
http://code.activestate.com/recipes/498072-implementing-an-immutable-dictionary/
http://code.activestate.com/recipes/414283-frozen-dictionaries/
http://corebio.googlecode.com/svn/trunk/apidocs/corebio.utils.frozendict-class.html
http://code.google.com/p/lingospot/source/browse/trunk/frozendict/frozendict.py
http://cmssdt.cern.ch/SDT/doxygen/CMSSW_4_4_2/doc/html/d6/d2f/classfrozendict_1_1frozendict.html
See also the recent discussion on python-list:
http://mail.python.org/pipermail/python-list/2012-February/1287658.html
--
See also the PEP 351.
Victor
diff --git a/Include/dictobject.h b/Include/dictobject.h
--- a/Include/dictobject.h
+++ b/Include/dictobject.h
@@ -84,10 +84,14 @@ struct _dictobject {
PyDictEntry *ma_table;
PyDictEntry *(*ma_lookup)(PyDictObject *mp, PyObject *key, Py_hash_t hash);
PyDictEntry ma_smalltable[PyDict_MINSIZE];
+
+/* only used by frozendict */
+Py_hash_t hash;
};
#endif /* Py_LIMITED_API */
PyAPI_DATA(PyTypeObject) PyDict_Type;
+PyAPI_DATA(PyTypeObject) PyFrozenDict_Type;
PyAPI_DATA(PyTypeObject) PyDictIterKey_Type;
PyAPI_DATA(PyTypeObject) PyDictIterValue_Type;
PyAPI_DATA(PyTypeObject) PyDictIterItem_Type;
@@ -97,6 +101,10 @@ PyAPI_DATA(PyTypeObject) PyDictValues_Ty
#define PyDict_Check(op) \
PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_DICT_SUBCLASS)
+#define PyFrozenDict_Check(op) \
+(PyDict_Check(op) || \
+ Py_TYPE(op) == &PyFrozenDict_Type || \
+ PyType_IsSubtype(Py_TYPE(op), &PyFrozenDict_Type))
#define PyDict_CheckExact(op) (Py_TYPE(op) == &PyDict_Type)
#define PyDictKeys_Check(op) (Py_TYPE(op) == &PyDictKeys_Type)
#define PyDictItems_Check(op) (Py_TYPE(op) == &PyDictItems_Type)
diff --git a/Lib/test/test_dict.py b/Lib/test/test_dict.py
--- a/Lib/test/test_dict.py
+++ b/Lib/test/test_dict.py
@@ -788,11 +788,54 @@ class Dict(dict):
class SubclassMappingTests(mapping_tests.BasicTestMappingProtocol):
type2test = Dict
+
+class FrozenDictTests(unittest.TestCase):
+def test_inherance(self):
+self.assertIsInstance(dict(),
+ frozendict)
+self.assertNotIsInstance(frozendict(),
+ dict)
+
+def test_copy(self):
+self.assertIsInstance(frozendict().copy(),
+ frozendict)
+
+def test_hash(self):
+self.assertEqual(hash(frozendict()),
+ hash(frozenset()))
+self.assertEqual(hash(frozendict({1: 2})),
+ hash(frozenset({(1, 2)})))
+
+def test_repr(self):
+self.assertEqual(repr(frozendict()), "frozendict({})")
+self.assertEqual(repr(frozendict(x=1)), "frozendict({'x': 1})")
+
+def test_readonly(self):
+
Re: [Python-Dev] PEP 414
On 2/27/2012 10:44 AM, Armin Ronacher wrote: On 2/27/12 1:55 AM, Terry Reedy wrote: I presume such a hook would simply remove 'u' prefixes and would run *much* faster than 2to3. If such a hook is satisfactory for 3.2, why would it not be satisfactory for 3.3? Agile development and unittests. Which I am all for. So the issue is not 3.3 versus 3.1/2, but development versus installation. I somehow did not get that reading the PEP but it seems a crucial point in its favor. An installation hook means that you need to install the package before running the tests. Which is fine for CI but horrible during development. "python3 run-tests.py" beats "make venv; install library; run testsuite" anytime in terms of development speed. That I can appreciate. It makes programming more fun. I presume you are saying that you would run the 'Python 3' tests quickly with 3.3 in your normal development cycle. Then, if you want your library to also run under 3.1/2, only occasionally (daily?) check that they also run under a 3.1/2 installation. That *does* make sense to me. -- Terry Jan Reedy ___ 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 414 - Unicode Literals for Python 3
Terry Reedy udel.edu> writes:
> This is a point, though this would be a one-time conversion by a 2to23
> converter that would be part of other needed conversions, some by hand.
> I presume that most 2.6 code has problems other than u'' when attempting
> to run under 3.x.
Right. In doing the Django port, the u() stuff took very little time - I wrote
a lib2to3 fixer to do it. A lot more time was spent in areas where the
bytes/text interfaces had not been thought through carefully, e.g. in the
crypto/hashing stuff - this is stuff that an automatic tools couldn't do.
After it was decided in the Django team to drop 2.5 support after Django 1.4
was released, the u('xxx') calls weren't needed any more. Another lib2to3 fixer
converted them back to 'xxx' for use with "from __future__ import
unicode_literals".
> > 2) Won't atually meet the aesthetic goal, as
> > it's uglier and slower under *both* Python 2 and Python 3.
>
> Less relevant. The minor ugliness would be in dual-version code, but not
> Python 3 itself.
And it would be reasonably easy to transition from u('xxx') -> 'xxx' when
support for 2.5 is dropped by a particular project, again using automation via
a lib2to3 fixer.
> I could claim that a solution that also works for 3.1 and 3.2 is a
> nobrainer. It depends on how one weighs different factors.
Yes. I feel the same way as Martin and Barry have expressed - it's a shame that
people are talking up the potential difficulties of porting to a single
code-base without the PEP change. Having been in the trenches with the Django
port, I don't feel that the Unicode literal part was really a major problem.
And I've now done *two* Django ports - one to a 2.5-compatible codebase with
u('xxx'), and one to a 2.6+ compatible codebase with unicode_literals and plain
'xxx'. I'm only keeping the latter one up to date with changes in Django trunk,
but both ports, though far from complete from a whole-project point of view,
got to the point where they passed the very large test suite.
On balance, though, I don't oppose the PEP. We can wish all we want for people
to do the right thing (as we see it), but wishing don't make it so.
Do I sense a certain amount of worry about the pace of the 2.x -> 3.x
transition? It feels like we're blinking first ;-)
Regards,
Vinay Sajip
___
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 415: Implementing PEP 409 differently
2012/2/27 Ethan Furman : > Benjamin Peterson wrote: >> >> 2012/2/26 Nick Coghlan : >>> >>> Thanks for writing that up. I'd be amenable if the PEP was clearly >>> updated to say that ``raise exc from cause`` would change from being >>> syntactic sugar for ``_hidden = exc; _hidden.__cause__ = cause; raise >>> exc`` (as it is now) to ``_hidden = exc; _hidden.__cause__ = cause; >>> _hidden.__suppress_context__ = True; raise exc``. The patch should >>> then be implemented accordingly (including appropriate updates to the >>> language reference). >> >> >> I add the following lines to the PEP: >> >> To summarize, ``raise exc from cause`` will be equivalent to:: >> >> exc.__cause__ = cause >> exc.__suppress_context__ = cause is None >> raise exc > > > So exc.__cause__ will be None both before and after `raise Exception from > None`? Yes. -- Regards, Benjamin ___ 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: Close issue #6210: Implement PEP 409
Antoine Pitrou wrote:
On Sun, 26 Feb 2012 09:02:59 +0100
nick.coghlan wrote:
+def get_output(self, code, filename=None):
+"""
+Run the specified code in Python (in a new child process)
and read the
+output from the standard error or from a file (if filename
is set).
+Return the output lines as a list.
+"""
We already have assert_python_ok and friends. It's not obvious what
this additional function achieves. Also, the "filename" argument is
never used.
+output = re.sub('Current thread 0x[0-9a-f]+',
+'Current thread XXX',
+output)
This looks like output from the faulthandler module. Why would
faulthandler kick in here?
That's because I stole those two functions from the faulthandler module.
Still learning where all the goodies are. Thanks for the tip about
assert_python_ok, etc.
~Ethan~
___
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 414
Terry Reedy udel.edu> writes:
> > An installation hook means that you need to install the package
> > before running the tests. Which is fine for CI but horrible during
> > development. "python3 run-tests.py" beats "make venv; install
> > library; run testsuite" anytime in terms of development speed.
>
> That I can appreciate. It makes programming more fun. I presume you are
> saying that you would run the 'Python 3' tests quickly with 3.3 in your
> normal development cycle. Then, if you want your library to also run
> under 3.1/2, only occasionally (daily?) check that they also run under a
> 3.1/2 installation. That *does* make sense to me.
Right, but Armin, while arguing against an installation hook for 2to3, is ISTM
arguing for an analogous hook for use with 3.2 (and earlier 3.x), which does a
smaller amount of work than 2to3 but is the same kind of beast.
The "programming fun" part is really an argument about a single codebase, which
I am completely in agreement with. But (summarising for my own benefit, but
someone please tell me if I've missed or misunderstood something) there are (at
least) three ways to get there:
1. Support only 2.6+ code, use from __future__ import unicode_literals, do away
with u'xxx' in favour of 'xxx'. This has been opposed because of
action-at-a-distance, but can be mitigated by strongly applied discipline on a
given project (so that everyone knows that all string literals are Unicode,
period). Of course, the same discipline needs to be applied to depended-upon
projects, too.
2. Support 2.5 or earlier, where you would have to use u('xxx') in place of
u'xxx', unless PEP 414 is accepted - but you would still have the exception
syntax hacks to upset you. This has been opposed because of performance and
productivity concerns, but I don't think these are yet proven in practice (for
performance, microbenchmarks notwithstanding - there's no data on more
representative workloads. For productivity I call shenanigans, since if we can
trust 2to3 to work automatically, we should be able to trust a 2to3 fixer to do
the work on u'xxx' -> u('xxx') or u('xxx') -> 'xxx' automatically).
3. Do one of the above, but approve this PEP and keep u'xxx' literals around for
some yet-to-be-determined time, but perhaps the life of Python 3. This has been
called a retrograde step, and one can see why; ISTM the main reason for
accepting this path is that some fairly vocal and respected developers don't
want to (as opposed to can't) take one of the other paths, and are basically
saying they're not porting their work to 3.x unless this path is taken. They're
saying between the lines that their views are representative of a fair number of
other less vocal developers, who are also not porting their code for the same
reason. (ISTM they're glossing over the other issues which come up in a 2.x ->
3.x port, which require more time to diagnose and fix than problems caused by
string literals.) But never mind that - if we're worried about the pace of the
2.x -> 3.x transition, we can appease these views fairly easily, so why not do
it? And while we're at it, we can perhaps also look at those pesky exception
clauses and see if we can't get 3.x to support 2.x exception syntax, to make
that porting job even easier ;-)
Regards,
Vinay Sajip
___
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 414 - Unicode Literals for Python 3
On Mon, 2012-02-27 at 13:44 -0500, Terry Reedy wrote:
> On 2/27/2012 1:01 PM, Chris McDonough wrote:
> > On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
> >> Eh? The 2.6 version would also be u('that'). That's the whole point
> >> of the idiom. You'll need a better counter argument than that.
> >
> > The best argument is that there already exists tons and tons of Python 2
> > code that already does:
> >
> >u'that'
> >
> > Needing to change it to:
> >
> >u('that')
> >
> > 1) Requires effort on the part of a from-Python-2-porter to service
> > the aesthetic and populist goal of not having an explicit
> > but redundant-under-Py3 literal syntax that says "this is text".
>
> This is a point, though this would be a one-time conversion by a 2to23
> converter that would be part of other needed conversions, some by hand.
> I presume that most 2.6 code has problems other than u'' when attempting
> to run under 3.x.
>
> > 2) Won't atually meet the aesthetic goal, as
> > it's uglier and slower under *both* Python 2 and Python 3.
>
> Less relevant. The minor ugliness would be in dual-version code, but not
> Python 3 itself.
>
> > So the populist argument remains.. "it's too confusing for people who
> > learn Python 3 as a new language to have a redundant syntax". But we've
> > had such a syntax in Python 2 for years with b'', and, as mentioned by
> > Armin's PEP single-quoted vs. triple-quoted strings forever.
> >
> > I just don't understand the pushback here at all.
>
> For one thing, u'' does not solve the problem for 3.1 and 3.2, while u()
> does. 3.2 will be around for years. For one example, it will be in the
> April long-term-support release of Ubuntu. For another, PyPy is working
> on a 3.2 compatible version to come out and be put into use this year.
I suspect not everyone lives and dies by OS distribution release support
policies. Many folks are both willing and capable to install a newer
Python on an older OS.
It's unfortunate that Python 3 < 3.3 does not have the syntax, and
people like me who have a long-term need to "straddle" are to blame; we
didn't provide useful feedback early enough to avoid the mistake. That
said, it seems like preventing a reintroduction of u'' literal syntax
would presume that two wrongs make a right. By our own schedule
estimate of Python 3 takeup, many people won't be even thinking about
porting any Python 2 code to 3 until years from now.
> > This is such a nobrainer.
>
> I could claim that a solution that also works for 3.1 and 3.2 is a
> nobrainer. It depends on how one weighs different factors.
An argument for the reintroduction of u'' literal syntax in Python >=
3.3 is not necessarily an argument against the utility of some automated
tool conversion support for porting a Python 2 app to a function-based
u() syntax so it can run in Python 3 < 3.2.
Tools like "2to23" or whatever can obviously be parameterized to emit
slightly different 3.2-compatible and 3.3-compatible code. It's almost
certain that it will need forward-version-aware modes like this anyway
as newer idioms are added to 3.X that make code prettier or more
efficient completely independent of u'' support.
Currently we handle 3.2 compatibility in packages that "straddle" via
six-like functions. We can continue doing this as necessary. If the
stdlib tooling helps, great. In an emit-function-based-syntax mode, the
conversion code would almost certainly need to rely on the import of an
externally downloadable module like six, for compatibility under both
Python 2 and 3 because there's no opportunity to go back in time and
make "u()" available for older releases unless it was like inlined in
every module during the conversion.
But if somebody only wants to target 3.3+, and it means they don't have
to rely on a six-like module to provide u(), great.
- C
___
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 414 - Unicode Literals for Python 3
On Mon, 27 Feb 2012 10:17:57 -0800, Guido van Rossum wrote:
> On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonough wrote:
> > The best argument is that there already exists tons and tons of Python 2
> > code that already does:
> >
> > Â u'that'
>
> +1
>
> > Needing to change it to:
> >
> > Â u('that')
> >
> > 1) Requires effort on the part of a from-Python-2-porter to service
> > Â the aesthetic and populist goal of not having an explicit
> > Â but redundant-under-Py3 literal syntax that says "this is text".
> >
> > 2) Won't actually meet the aesthetic goal, as
> > Â it's uglier and slower under *both* Python 2 and Python 3.
> >
> > So the populist argument remains.. "it's too confusing for people who
> > learn Python 3 as a new language to have a redundant syntax". Â But we've
> > had such a syntax in Python 2 for years with b'', and, as mentioned by
> > Armin's PEP single-quoted vs. triple-quoted strings forever.
> >
> > I just don't understand the pushback here at all. Â This is such a
> > nobrainer.
It's obviously not a *no*-brainer or you wouldn't be getting pushback :)
I view most of the pushback as people wanting to make sure all the
options have been carefully considered. This should all be documented
in the PEP.
> I agree. Just let's start deprecating it too, so that once Python 2.x
> compatibility is no longer relevant we can eventually stop supporting
> it (though that may have to wait until Python 4...). We need to send
> *some* sort of signal that this is a compatibility hack and that no
> new code should use it. Maybe a SilentDeprecationWarning?
Isn't that what PendingDeprecationWarning is? This seems like the kind
of use case that was introduced for (though it is less used now that
DeprecationWarnings are silent by default).
--David
___
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 414 - Unicode Literals for Python 3
Am 27.02.2012 18:05, schrieb Ethan Furman:
> Martin v. Löwis wrote:
>> Am 26.02.2012 07:06, schrieb Nick Coghlan:
>>> On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum
>>> wrote:
A small quibble: I'd like to see a benchmark of a 'u' function
implemented in C.
>>> Even if it was quite fast, I don't think such a function would bring
>>> the same benefits as restoring support for u'' literals.
>>
>> You claim that, but your argument doesn't actually support that claim
>> (or I fail to see the argument).
>
> Python 2.6 code:
>this = u'that'
>
> Python 3.3 code:
>this = u('that')
>
> Not source compatible, not elegant. (Even though 2to3 could make this
> fix, it's still kinda ugly.)
No:
Python 2.6 code
this = u('that')
Python 3.3 code
this = u('that')
It *is* source compatible, and 100% so. As for elegance: I find the u
prefix fairly inelegant already; the function removes just a little
more elegance.
Regards,
Martin
___
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 414 - Unicode Literals for Python 3
On 2/27/2012 1:17 PM, Guido van Rossum wrote: On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonough wrote: The best argument is that there already exists tons and tons of Python 2 code that already does: u'that' +1 I just don't understand the pushback here at all. This is such a nobrainer. I agree. Just let's start deprecating it too, so that once Python 2.x compatibility is no longer relevant we can eventually stop supporting it (though that may have to wait until Python 4...). We need to send *some* sort of signal that this is a compatibility hack and that no new code should use it. Maybe a SilentDeprecationWarning? One possibility: leave Ref Man 2.4.1. *String and Bytes literals* as is. Add ''' 2.4.1.1 Deprecated u prefix. To aid people who want to update Python 2 code to also run under Python 3, string literals may optionally be prefixed with "u" or "U". For this purpose, but only for this purpose, the grammar actually reads stringprefix::= "r" | "R" | "ur" | "Ur" | "uR" | "UR" Since "u" and "U" will go away again some year, they should only be used for such multi-version code and not in code only intended for Python 3. See PEP 414. Version added: 3.3 ''' I think the PEP should have exaggerated statements removed, perhaps be shortened, explain how to patch code on installation for 3.1/2, and have something at the top pointing to that explanation. -- Terry Jan Reedy ___ 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 414 - Unicode Literals for Python 3
Chris McDonough plope.com> writes:
> I suspect not everyone lives and dies by OS distribution release support
> policies. Many folks are both willing and capable to install a newer
> Python on an older OS.
But many folks aren't, and lament the slow pace of Python version adoption on
e.g. Red Hat and CentOS.
> It's unfortunate that Python 3 < 3.3 does not have the syntax, and
> people like me who have a long-term need to "straddle" are to blame; we
> didn't provide useful feedback early enough to avoid the mistake. That
> said, it seems like preventing a reintroduction of u'' literal syntax
> would presume that two wrongs make a right. By our own schedule
> estimate of Python 3 takeup, many people won't be even thinking about
> porting any Python 2 code to 3 until years from now.
If the lack of u'' literal is what's holding them back, that's germane to the
discussion of the PEP. If it's not, then why propose the PEP?
> An argument for the reintroduction of u'' literal syntax in Python >=
> 3.3 is not necessarily an argument against the utility of some automated
> tool conversion support for porting a Python 2 app to a function-based
> u() syntax so it can run in Python 3 < 3.2.
I thought the argument was more about backtracking (or not) from Python 3's
design decision to use 'xxx' for text and b'yyy' for bytes. That's the only
"wrong" we're talking about for this PEP, right?
> Currently we handle 3.2 compatibility in packages that "straddle" via
> six-like functions. We can continue doing this as necessary. If the
> stdlib tooling helps, great. In an emit-function-based-syntax mode, the
> conversion code would almost certainly need to rely on the import of an
> externally downloadable module like six, for compatibility under both
> Python 2 and 3 because there's no opportunity to go back in time and
> make "u()" available for older releases unless it was like inlined in
> every module during the conversion.
>
> But if somebody only wants to target 3.3+, and it means they don't have
> to rely on a six-like module to provide u(), great.
If you only need to straddle from 2.6 onwards, then u('') isn't an issue at all,
right now, is it?
If you need to straddle from 2.5 downwards, there are other issues to be
addressed, like exception syntax, 'with' and so forth - so making u'' available
doesn't make the port a no-brainer. And if you bite the bullet and decide to do
the port anyway, converting u'' to u('') won't be a problem unless you (a) can't
use a fixer to automate the conversion or (b) the function call overhead cannot
be borne. I'm not sure either of those objections (can't use fixer, call
overhead excessive) have been made with sufficient force (i.e., data) in the
discussion so far.
Regards,
Vinay Sajip
___
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 414 - Unicode Literals for Python 3
>> Eh? The 2.6 version would also be u('that'). That's the whole point
>> of the idiom. You'll need a better counter argument than that.
>
> So the idea is to convert the existing 2.6 code to use parenthesis as
> well? (I obviously haven't read the PEP -- my apologies.)
Well, if you didn't, you wouldn't have the same sources on 2.x and 3.x.
And if that was ok, you wouldn't need the u() function in 3.x at all,
since plain string literals are *already* unicode strings there.
Regards,
Martin
___
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 414 - Unicode Literals for Python 3
On Mon, 27 Feb 2012 14:50:21 -0500, Chris McDonough wrote: > Currently we handle 3.2 compatibility in packages that "straddle" via > six-like functions. We can continue doing this as necessary. If the It seems to me that this undermines your argument in favor of u''. Why can't you just continue to do the above for 3.3 and beyond? Frankly, *I'm* not worried about the uptake pace of Python3. It feels to me like it is pretty much on schedule, if not ahead of it. But to repeat, I'm not voting -1 here, I'm playing devil's advocate. --David ___ 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] Marking packaging-related PEPs as Finished after fixing some bugs in them
On 2/27/2012 6:50 AM, Antoine Pitrou wrote: 'rc' makes sense to most people while 'c' is generally unheard of. 'rc' following 'a' and 'b' only makes sense to people who are used to it and know what it means. 'c' for 'candidate' makes more sense to me both a decade ago and now. 'rc' is inconsistent. Why not 'ra' for 'release alpha' or 'ar' for 'alpha release'? In other words, all releases are releases, so why not be consistent and either always or never include 'r'? (Never would be better since always is redundant.) I suspect many non-developer users find 'rc' as surprising as I did. -- Terry Jan Reedy ___ 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 414 - Unicode Literals for Python 3
On Mon, 2012-02-27 at 15:23 -0500, R. David Murray wrote: > On Mon, 27 Feb 2012 14:50:21 -0500, Chris McDonough wrote: > > Currently we handle 3.2 compatibility in packages that "straddle" via > > six-like functions. We can continue doing this as necessary. If the > > It seems to me that this undermines your argument in favor of u''. > Why can't you just continue to do the above for 3.3 and beyond? I really don't know how long I'll need to do future development in the subset language of Python 2 and Python 3 because I can't predict the future. It could be two years, it might be five. Who knows. But I do know that I'm going to be developing in the subset of Python that currently runs on Python 2 >= 2.6 and Python 3 >= 3.2 for at least a year. And that will suck, because that language is a much less fun language in which to develop than either Python 2 or Python 3. Frankly, it's a pretty bad language. If we make this change now, it means a year from now I'll be able to develop in a slightly less sucky subset language if I choose to drop support for 3.2. And people who don't try to support Python 3 at all til then will never have to program in the suckiest subset like I will have had to. Note that u'' literals are sort of the tip of the iceberg here; supporting them will obviously not make development under the subset an order of magnitude less sucky, just a tiny little bit less sucky. There are other extremely annoying things, like str(bytes) returning the repr of a bytestring on Python 3. That's almost as irritating as the absence of u'' literals, but we have to evaluate one thing at a time. - C ___ 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 415: Implementing PEP 409 differently
Benjamin Peterson wrote: 2012/2/27 Ethan Furman : Benjamin Peterson wrote: 2012/2/26 Nick Coghlan : Thanks for writing that up. I'd be amenable if the PEP was clearly updated to say that ``raise exc from cause`` would change from being syntactic sugar for ``_hidden = exc; _hidden.__cause__ = cause; raise exc`` (as it is now) to ``_hidden = exc; _hidden.__cause__ = cause; _hidden.__suppress_context__ = True; raise exc``. The patch should then be implemented accordingly (including appropriate updates to the language reference). I add the following lines to the PEP: To summarize, ``raise exc from cause`` will be equivalent to:: exc.__cause__ = cause exc.__suppress_context__ = cause is None raise exc So exc.__cause__ will be None both before and after `raise Exception from None`? Yes. And the primary advantage being that we don't lose an already set __cause__ (since most of the time __cause__ would be empty and we're just suppressing __context__)... seems like a good idea. +1 As far as Ellipsis goes -- I do think it works well in this case, but I am not opposed to changing it. I do think we do ourselves a disservice if we refuse to use it in other situations because "it's only for slices". ~Ethan~ ___ 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 414 - Unicode Literals for Python 3
Chris McDonough plope.com> writes: > I really don't know how long I'll need to do future development in the > subset language of Python 2 and Python 3 because I can't predict the > future. It could be two years, it might be five. Who knows. > > But I do know that I'm going to be developing in the subset of Python > that currently runs on Python 2 >= 2.6 and Python 3 >= 3.2 for at least > a year. And that will suck, because that language is a much less fun > language in which to develop than either Python 2 or Python 3. Frankly, > it's a pretty bad language. What exactly is it that makes it so bad? Since you're developing for >= 2.6, what stops you from using "from __future__ import unicode_literals" and 'xxx' for text and b'yyy' for bytes? Then you would be working in essentially Python 3.x, at least as far as string literals go. The conversion time will be very small compared to the year time-frame you're talking about. > If we make this change now, it means a year from now I'll be able to > develop in a slightly less sucky subset language if I choose to drop > support for 3.2. And people who don't try to support Python 3 at all > til then will never have to program in the suckiest subset like I will > have had to. And if we don't make the change now and you change your code to use unicode_literals, convert u'xxx' -> 'xxx' and then change the places where you really meant to use bytes, that'll be a one-off change after which you will be working on a common codebase which works on 2.6+ and 3.0+, and as far as string literals are concerned you'll be working in the hopefully non-sucky 3.x syntax. > Note that u'' literals are sort of the tip of the iceberg here; > supporting them will obviously not make development under the subset an > order of magnitude less sucky, just a tiny little bit less sucky. There > are other extremely annoying things, like str(bytes) returning the repr > of a bytestring on Python 3. That's almost as irritating as the absence > of u'' literals, but we have to evaluate one thing at a time. Yes, but making a backward step like reintroducing u'' just to make things a tiny little bit sucky doesn't seem to me to be worth it, because then >= 3.3 is different to 3.2 and earlier. Armin's suggestion of an install-time fixer is analogous to running 2to3 after every change, if you're trying to support 3.2 and 3.3+ at the same time, isn't it? You can't just edit-and-test, which to me is the main benefit of a single codebase. Regards, Vinay Sajip ___ 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 414 - Unicode Literals for Python 3
On Feb 27, 2012, at 03:39 PM, Chris McDonough wrote: >Note that u'' literals are sort of the tip of the iceberg here; >supporting them will obviously not make development under the subset an >order of magnitude less sucky, just a tiny little bit less sucky. There >are other extremely annoying things, like str(bytes) returning the repr >of a bytestring on Python 3. That's almost as irritating as the absence >of u'' literals, but we have to evaluate one thing at a time. Yeah, that one has bitten me many times, and for me it *is* more irritating because it's harder to work around. -Barry ___ 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 414 - Unicode Literals for Python 3
On Mon, 2012-02-27 at 20:18 +, Vinay Sajip wrote:
> Chris McDonough plope.com> writes:
>
> > I suspect not everyone lives and dies by OS distribution release support
> > policies. Many folks are both willing and capable to install a newer
> > Python on an older OS.
>
> But many folks aren't, and lament the slow pace of Python version adoption on
> e.g. Red Hat and CentOS.
It's great to have software that installs easily. That said, the
versions of Python that my software supports is (and has to be) be my
choice.
As far as I can tell, there are maybe three or four people (besides me)
using my software on Python 3 right now. They have it pretty rough:
lackluster library support and they have to constantly mentally
transliterate third-party example code to code that works under Python
3. They are troopers!
None of them would so much as bat an eyelash if I told them today they
had to use Python 3.3 (if it existed in a final released form anyway) to
use my software. It's just a minor drop in the bucket of inconvenience
they have to currently withstand.
> > It's unfortunate that Python 3 < 3.3 does not have the syntax, and
> > people like me who have a long-term need to "straddle" are to blame; we
> > didn't provide useful feedback early enough to avoid the mistake. That
> > said, it seems like preventing a reintroduction of u'' literal syntax
> > would presume that two wrongs make a right. By our own schedule
> > estimate of Python 3 takeup, many people won't be even thinking about
> > porting any Python 2 code to 3 until years from now.
>
> If the lack of u'' literal is what's holding them back, that's germane to the
> discussion of the PEP. If it's not, then why propose the PEP?
Like I said in an earlier email, u'' literal support is by no means the
only issue for people who want to straddle. But it *is* an issue, and
it's incredibly low-hanging fruit with near-zero real-world impact if it
is reintroduced.
> > An argument for the reintroduction of u'' literal syntax in Python >=
> > 3.3 is not necessarily an argument against the utility of some automated
> > tool conversion support for porting a Python 2 app to a function-based
> > u() syntax so it can run in Python 3 < 3.2.
>
> I thought the argument was more about backtracking (or not) from Python 3's
> design decision to use 'xxx' for text and b'yyy' for bytes. That's the only
> "wrong" we're talking about for this PEP, right?
You cast it as "backtracking" to reintroduce the syntax, but things have
changed from when the decision to omit it was first made. Its omission
introduces pain in a world where it's expected that we don't use 2to3 to
automatically translate code at installation time.
> > Currently we handle 3.2 compatibility in packages that "straddle" via
> > six-like functions. We can continue doing this as necessary. If the
> > stdlib tooling helps, great. In an emit-function-based-syntax mode, the
> > conversion code would almost certainly need to rely on the import of an
> > externally downloadable module like six, for compatibility under both
> > Python 2 and 3 because there's no opportunity to go back in time and
> > make "u()" available for older releases unless it was like inlined in
> > every module during the conversion.
> >
> > But if somebody only wants to target 3.3+, and it means they don't have
> > to rely on a six-like module to provide u(), great.
>
> If you only need to straddle from 2.6 onwards, then u('') isn't an issue at
> all,
> right now, is it?
If you look at a piece of code as something that exists in one of the
two states "ported" or "not-ported", sure. But code often needs to be
changed, and people of varying buy-in levels need to understand and
change such code. It's just much easier for them to assume that the
same syntax works on some versions of Python 2 and Python 3 and be done
with it rather than need to explain the introduction of a function that
only exists to paper over a syntax omission.
> If you need to straddle from 2.5 downwards, there are other issues to be
> addressed, like exception syntax, 'with' and so forth - so making u''
> available
> doesn't make the port a no-brainer. And if you bite the bullet and decide to
> do
> the port anyway, converting u'' to u('') won't be a problem unless you (a)
> can't
> use a fixer to automate the conversion or (b) the function call overhead
> cannot
> be borne. I'm not sure either of those objections (can't use fixer, call
> overhead excessive) have been made with sufficient force (i.e., data) in the
> discussion so far.
>
> Regards,
>
> Vinay Sajip
>
>
>
> ___
> 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/lists%40plope.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3
On 27 February 2012 20:39, Chris McDonough wrote: > Note that u'' literals are sort of the tip of the iceberg here; > supporting them will obviously not make development under the subset an > order of magnitude less sucky, just a tiny little bit less sucky. There > are other extremely annoying things, like str(bytes) returning the repr > of a bytestring on Python 3. That's almost as irritating as the absence > of u'' literals, but we have to evaluate one thing at a time. So. Am I misunderstanding here, or are you suggesting that this particular PEP doesn't help you much, but if it's accepted, it represents "the thin end of the wedge" for a series of subsequent PEPs suggesting fixes for a number of other "extremely annoying things"...? I'm sure that's not what you meant, but it's certainly what it sounded like to me! Paul. ___ 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 414 - Unicode Literals for Python 3
On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote: > On 27 February 2012 20:39, Chris McDonough wrote: > > Note that u'' literals are sort of the tip of the iceberg here; > > supporting them will obviously not make development under the subset an > > order of magnitude less sucky, just a tiny little bit less sucky. There > > are other extremely annoying things, like str(bytes) returning the repr > > of a bytestring on Python 3. That's almost as irritating as the absence > > of u'' literals, but we have to evaluate one thing at a time. > > So. Am I misunderstanding here, or are you suggesting that this > particular PEP doesn't help you much, but if it's accepted, it > represents "the thin end of the wedge" for a series of subsequent PEPs > suggesting fixes for a number of other "extremely annoying things"...? > > I'm sure that's not what you meant, but it's certainly what it sounded > like to me! I'm way too lazy. The political wrangling is just too draining (especially over something so trivial). But I will definitely support other proposals that make it easier to straddle, sure. - C ___ 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 2012-02-27, at 19:53 , Victor Stinner wrote: > Rationale > = > > A frozendict type is a common request from users and there are various > implementations. There are two main Python implementations: > > * "blacklist": frozendict inheriting from dict and overriding methods > to raise an exception when trying to modify the frozendict > * "whitelist": frozendict not inheriting from dict and only implement > some dict methods, or implement all dict methods but raise exceptions > when trying to modify the frozendict > > The blacklist implementation has a major issue: it is still possible > to call write methods of the dict class (e.g. dict.set(my_frozendict, > key, value)). > > The whitelist implementation has an issue: frozendict and dict are not > "compatible", dict is not a subclass of frozendict (and frozendict is > not a subclass of dict). This may be an issue at the C level (I'm not sure), but since this would be a Python 3-only collection, "user" code (in Python) should/would generally be using abstract base classes, so type-checking would not be an issue (as in Python code performing `isinstance(a, dict)` checks naturally failing on `frozendict`) Plus `frozenset` does not inherit from `set`, it's a whitelist reimplementation and I've never known anybody to care. So there's that precedent. And of course there's no inheritance relationship between lists and tuples. > * frozendict has not the following methods: clear, __delitem__, pop, > popitem, setdefault, __setitem__ and update. As tuple/frozenset has > less methods than list/set. It'd probably be simpler to define that frozendict is a Mapping (where dict is a MutableMapping). And that's clearer. > * Make dict inherits from frozendict Isn't that the other way around from the statement above? Not that I'd have an issue with it, it's much cleaner, but there's little gained by doing so since `isinstance(a, dict)` will still fail if `a` is a frozendict. > * Add a frozendict abstract base class to collections? Why? There's no `dict` ABC, and there are already a Mapping and a MutableMapping ABC which fit the bill no? ___ 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 414 - Unicode Literals for Python 3
On Mon, 2012-02-27 at 21:03 +, Vinay Sajip wrote: > Chris McDonough plope.com> writes: > > > I really don't know how long I'll need to do future development in the > > subset language of Python 2 and Python 3 because I can't predict the > > future. It could be two years, it might be five. Who knows. > > > > But I do know that I'm going to be developing in the subset of Python > > that currently runs on Python 2 >= 2.6 and Python 3 >= 3.2 for at least > > a year. And that will suck, because that language is a much less fun > > language in which to develop than either Python 2 or Python 3. Frankly, > > it's a pretty bad language. > > What exactly is it that makes it so bad? Since you're developing for >= 2.6, > what stops you from using "from __future__ import unicode_literals" and 'xxx' > for text and b'yyy' for bytes? Then you would be working in essentially Python > 3.x, at least as far as string literals go. The conversion time will be very > small compared to the year time-frame you're talking about. > > > If we make this change now, it means a year from now I'll be able to > > develop in a slightly less sucky subset language if I choose to drop > > support for 3.2. And people who don't try to support Python 3 at all > > til then will never have to program in the suckiest subset like I will > > have had to. > > And if we don't make the change now and you change your code to use > unicode_literals, convert u'xxx' -> 'xxx' and then change the places where you > really meant to use bytes, that'll be a one-off change after which you will be > working on a common codebase which works on 2.6+ and 3.0+, and as far as > string > literals are concerned you'll be working in the hopefully non-sucky 3.x > syntax. > > > Note that u'' literals are sort of the tip of the iceberg here; > > supporting them will obviously not make development under the subset an > > order of magnitude less sucky, just a tiny little bit less sucky. There > > are other extremely annoying things, like str(bytes) returning the repr > > of a bytestring on Python 3. That's almost as irritating as the absence > > of u'' literals, but we have to evaluate one thing at a time. > > Yes, but making a backward step like reintroducing u'' just to make things a > tiny little bit sucky doesn't seem to me to be worth it, because then >= 3.3 > is > different to 3.2 and earlier. Armin's suggestion of an install-time fixer is > analogous to running 2to3 after every change, if you're trying to support 3.2 > and 3.3+ at the same time, isn't it? You can't just edit-and-test, which to me > is the main benefit of a single codebase. The downsides of a unicode_literals future import are spelled out in the PEP: http://www.python.org/dev/peps/pep-0414/#rationale-and-goals - C ___ 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
> This may be an issue at the C level (I'm not sure), but since this would > be a Python 3-only collection, "user" code (in Python) should/would > generally be using abstract base classes, so type-checking would not > be an issue (as in Python code performing `isinstance(a, dict)` checks > naturally failing on `frozendict`) > > Plus `frozenset` does not inherit from `set`, it's a whitelist > reimplementation and I've never known anybody to care. So there's > that precedent. And of course there's no inheritance relationship > between lists and tuples. At a second thought, I realized that it does not really matter. frozendict and dict can be "unrelated" (no inherance relation). Victor ___ 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 414 - Unicode Literals for Python 3
Martin v. Löwis wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
So the idea is to convert the existing 2.6 code to use parenthesis as
well? (I obviously haven't read the PEP -- my apologies.)
Well, if you didn't, you wouldn't have the same sources on 2.x and 3.x.
And if that was ok, you wouldn't need the u() function in 3.x at all,
since plain string literals are *already* unicode strings there.
True -- but I would rather have u'' in 2.6 and 3.3 than u('') in 2.6 and
3.3.
~Ethan~
___
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 414 - Unicode Literals for Python 3
Hi, On 2/27/12 4:44 PM, mar...@v.loewis.de wrote: > Maybe I'm missing something, but there doesn't seem to be a benchmark > that measures the 2to3 performance, supporting the claim that it > runs "two orders of magnitude" slower (which I'd interpret as a > factor of 100). My Jinja2+Werkzeug's testsuite combined takes 2 seconds to run (Werkzeug actually takes 3 because it pauses for two seconds in a cache expiration test). 2to3 takes 45 seconds to run. And those are small code bases (15K lines combined). It's not exactly two orders of magnitude so I will probably change the writing to "just" 20 times slower but it illustrates the point. Regards, Armin ___ 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 414 - Unicode Literals for Python 3
On Mon, 27 Feb 2012 13:09:24 -0800
Ethan Furman wrote:
> Martin v. Löwis wrote:
> >>> Eh? The 2.6 version would also be u('that'). That's the whole point
> >>> of the idiom. You'll need a better counter argument than that.
> >> So the idea is to convert the existing 2.6 code to use parenthesis as
> >> well? (I obviously haven't read the PEP -- my apologies.)
> >
> > Well, if you didn't, you wouldn't have the same sources on 2.x and 3.x.
> > And if that was ok, you wouldn't need the u() function in 3.x at all,
> > since plain string literals are *already* unicode strings there.
>
> True -- but I would rather have u'' in 2.6 and 3.3 than u('') in 2.6 and
> 3.3.
You don't want to be 3.2-compatible?
Antoine.
___
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 414 - Unicode Literals for Python 3
Chris McDonough plope.com> writes:
> It's great to have software that installs easily. That said, the
> versions of Python that my software supports is (and has to be) be my
> choice.
Of course. And if I understand correctly, that's 2.6, 2.7, 3.2 and later
versions. I'll ignore 2.5 and earlier in this specific reply.
> None of them would so much as bat an eyelash if I told them today they
> had to use Python 3.3 (if it existed in a final released form anyway) to
> use my software. It's just a minor drop in the bucket of inconvenience
> they have to currently withstand.
Their pain (lacklustre library support and transliterating examples from 2.x to
3.x) would be the same under 3.2 and 3.3 (unless for some perverse reason people
only made libraries work under one of 3.2 and 3.3, but not both). Is it really
that hard to transliterate 2.x examples to 3.x in the literal-string dimension?
I can't believe it is, as the target audience is programmers.
> > If the lack of u'' literal is what's holding them back, that's germane to
> > the
> > discussion of the PEP. If it's not, then why propose the PEP?
>
> Like I said in an earlier email, u'' literal support is by no means the
> only issue for people who want to straddle. But it *is* an issue, and
> it's incredibly low-hanging fruit with near-zero real-world impact if it
> is reintroduced.
But the implication of the PEP is that lack of u'' support is a major hindrance
to porting, justifying the production of the PEP and this discussion. And it's
not low-hanging fruit with near-zero real-world impact if we're going to
deprecate it at some point (which Guido was talking about) - you're just moving
the pain to a later date, unless we don't ever deprecate.
I feel, like some others, that 'xxx' is natural for text, u'xxx' is inelegant by
comparison, and u('xxx') a little more inelegant still.
However, allowing u'' syntax in 3.3 as per this PEP, but allowing it to be
optional, allows any combination of u'xxx' and 'xxx' in code in a 3.x context,
which doesn't see to me to be an ideal situation especially if you have
hit-and-run contributors who are not necessarily attuned to project conventions.
> You cast it as "backtracking" to reintroduce the syntax, but things have
> changed from when the decision to omit it was first made. Its omission
> introduces pain in a world where it's expected that we don't use 2to3 to
> automatically translate code at installation time.
I'm calling it like it is. "reintroduce" in this case means undoing something
already done, so it's appropriate to say "backtracking".
I don't agree that things have changed. If I want to write code that works on
2.x and 3.x without the pain of running 2to3 after every change, and I'm only
interested in supporting >= 2.6 (your situation, IIUC), then I use "from
__future__ import unicode_literals" - that's what it was created for, wasn't
it? - and use 'xxx' where I need text, b'xxx' where I need bytes, and a function
to deliver native strings where they're needed.
If I have a 2.x project full of u'' code which I need to bring into this
approach, then I run 2to3, review what it tells me, make the changes necessary
(as far as literals go, that's adding the unicode_literals import to all files,
and converting u'xxx' -> 'xxx'. When I test the result, I will find numerous
failures, some of which point to places where I should have used native strings
(e.g. kwargs keys), which I then fix. Other areas will be where I needed to use
bytes (e.g. encoding/decoding/hashing), which I will also fix. I use six or a
similar approach to sort out any other issues which crop up, e.g. metaclass
syntax, execfile, and so on.
After a relatively modest amount of work, I have a codebase that works on 2.x
and 3.x, and all I have to remember is that 'xxx' is Unicode, and if I create a
new module, I need to add the future import (on the assumption that I might add
literal strings later, if not now). After that, it seems to be plain sailing,
and I don't have to switch mental gears re. string literals.
> If you look at a piece of code as something that exists in one of the
> two states "ported" or "not-ported", sure. But code often needs to be
> changed, and people of varying buy-in levels need to understand and
> change such code. It's just much easier for them to assume that the
> same syntax works on some versions of Python 2 and Python 3 and be done
> with it rather than need to explain the introduction of a function that
> only exists to paper over a syntax omission.
Well, according to the approach I described above, that one thing needs to be
the present 3.x syntax - 'xxx' is text, b'xxx' is bytes, and f('xxx') is native
string (or whatever name you want instead of f). With the unicode_literals
import, that syntax works on 2.6+ and 3.2+, so ISTM it should work within the
constraints you mentioned for your software.
Regards,
Vinay Sajip
___
Python-Dev mailing list
P
Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3
Hi, On 2/27/12 9:36 PM, Antoine Pitrou wrote: > You don't want to be 3.2-compatible? See the PEP. It shows how it would still be 3.2 compatible at installation time due to an installation hook that would be provided. Regards, Armin ___ 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 414 - Unicode Literals for Python 3
On 2/27/2012 1:01 PM, Chris McDonough wrote: I just don't understand the pushback here at all. This is such a nobrainer. Last December, Armin wrote in http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/ "And in my absolutely personal opinion Python 3.3/3.4 should be more like Python 2* and Python 2.8 should happen and be a bit more like Python 3." * he wrote '3' but obviously mean '2'. Today, you made it clear that you regard this PEP as one small step in reverting Python 3 toward Python 2 and that you support the above goal. *That* is what some are pushing back against. -- Terry Jan Reedy ___ 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 414 - Unicode Literals for Python 3
27.02.12 22:19, Terry Reedy написав(ла): Since "u" and "U" will go away again some year, they should only be used for such multi-version code and not in code only intended for Python 3. See PEP 414. And not for code intended for both Python 2 and Python 3.0-3.2. ___ 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 414 - Unicode Literals for Python 3
Ethan Furman stoneleaf.us> writes:
> True -- but I would rather have u'' in 2.6 and 3.3 than u('') in 2.6 and
> 3.3.
You don't need u('') in 2.6 - why do you think you need it there?
If you don't implement this PEP, you can have, *uniformly* across 2.6, 2.7 and
all 3.x versions, 'xxx' for text and b'yyy' for bytes. For 2.6 you would have to
add "from __future__ import unicode_literals", and this might uncover places
where you need to change things to use bytes or native strings - either because
of bugs in the original code, or drawbacks in a Python version where you can't
use Unicode as keys in a kwargs dictionary, or some API that wants you to use
str explicitly. But at least some of those places will be things you would have
to address anyway, when porting, whatever the state of Unicode literal support.
Regards,
Vinay Sajip
___
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 414 - Unicode Literals for Python 3
On 2/27/2012 1:17 PM, Guido van Rossum wrote: I just don't understand the pushback here at all. This is such a nobrainer. I agree. Just let's start deprecating it too, so that once Python 2.x compatibility is no longer relevant we can eventually stop supporting it (though that may have to wait until Python 4...). We need to send *some* sort of signal that this is a compatibility hack and that no new code should use it. Maybe a SilentDeprecationWarning? Before we make this change, I would like to know if this is Armin's last proposal to revert Python 3 toward Python 2 or merely the first in a series. I question this because last December Armin wrote "And in my absolutely personal opinion Python 3.3/3.4 should be more like Python 2* and Python 2.8 should happen and be a bit more like Python 3." * he wrote '3' but obviously means '2'. http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/ Chris has also made it clear that he (also?) would like more reversions. -- Terry Jan Reedy ___ 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] PEP 414 - Unicode Literals for Python 3
In http://mail.python.org/pipermail/python-dev/2012-February/116953.html Terry J. Reedy wrote: > I presume that most 2.6 code has problems other than u'' when > attempting to run under 3.x. Why? If you're talking about generic code that has seen minimal changes since 2.0, sure. But I think this request is specifically for projects that are thinking about python 3, but are trying to use a single source base regardless of version. Using an automatic translation step means that python (or at least python 3) would no longer be the actual source code. I've worked with enough generated "source" code in other languages that it is worth some pain to avoid even a slippery slope. By the time you drop 2.5, the "subset" language is already pretty good; if I have to write something version-specific, I prefer to treat that as a sign that I am using the wrong approach. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ 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 414 - Unicode Literals for Python 3
Hi, On 2/27/12 9:47 PM, Serhiy Storchaka wrote: > And not for code intended for both Python 2 and Python 3.0-3.2. Even then since you can use the installation time hook to strip off the 'u' prefixes. Regards, Armin ___ 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 414 - Unicode Literals for Python 3
On Mon, 27 Feb 2012 16:54:51 -0500 Terry Reedy wrote: > On 2/27/2012 1:17 PM, Guido van Rossum wrote: > > >> I just don't understand the pushback here at all. This is such a > >> nobrainer. > > > I agree. Just let's start deprecating it too, so that once Python 2.x > > compatibility is no longer relevant we can eventually stop supporting > > it (though that may have to wait until Python 4...). We need to send > > *some* sort of signal that this is a compatibility hack and that no > > new code should use it. Maybe a SilentDeprecationWarning? > > Before we make this change, I would like to know if this is Armin's last > proposal to revert Python 3 toward Python 2 or merely the first in a > series. I question this because last December Armin wrote > > "And in my absolutely personal opinion Python 3.3/3.4 should be more > like Python 2* and Python 2.8 should happen and be a bit more like > Python 3." > * he wrote '3' but obviously means '2'. > http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/ > > Chris has also made it clear that he (also?) would like more reversions. Please. While I'm not strongly in favour of the PEP, this kind of argument is dishonest. Whatever Armin's secret wishes may be, his PEP should be judged on its own grounds. Thank you Antoine. ___ 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 414 - Unicode Literals for Python 3
On Mon, 27 Feb 2012 16:16:39 -0500, Chris McDonough wrote: > On Mon, 2012-02-27 at 21:03 +, Vinay Sajip wrote: > > Yes, but making a backward step like reintroducing u'' just to make things a > > tiny little bit sucky doesn't seem to me to be worth it, because then >= > > 3.3 is > > different to 3.2 and earlier. Armin's suggestion of an install-time fixer is > > analogous to running 2to3 after every change, if you're trying to support > > 3.2 > > and 3.3+ at the same time, isn't it? You can't just edit-and-test, which to > > me > > is the main benefit of a single codebase. > > The downsides of a unicode_literals future import are spelled out in the > PEP: > > http://www.python.org/dev/peps/pep-0414/#rationale-and-goals But the PEP doesn't address the unicode_literals plus str() approach. That is, the rationale currently makes a false claim. --David ___ 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 414 - Unicode Literals for Python 3
On Mon, 2012-02-27 at 21:43 +, Vinay Sajip wrote:
> Chris McDonough plope.com> writes:
>
> > It's great to have software that installs easily. That said, the
> > versions of Python that my software supports is (and has to be) be my
> > choice.
>
> Of course. And if I understand correctly, that's 2.6, 2.7, 3.2 and later
> versions. I'll ignore 2.5 and earlier in this specific reply.
>
> > None of them would so much as bat an eyelash if I told them today they
> > had to use Python 3.3 (if it existed in a final released form anyway) to
> > use my software. It's just a minor drop in the bucket of inconvenience
> > they have to currently withstand.
>
> Their pain (lacklustre library support and transliterating examples from 2.x
> to
> 3.x) would be the same under 3.2 and 3.3 (unless for some perverse reason
> people
> only made libraries work under one of 3.2 and 3.3, but not both).
If I had it to do all over again and a Python 3.X with unicode literals
had been available, I might not have targeted Python 3.2 at all. I
don't consider that perverse, I just consider it "Python 3 water under
the bridge". Python 3.0 and 3.1 were this for me; I paid almost no
attention to them at all. Python 3.2 will be that thing for many other
people.
> > Like I said in an earlier email, u'' literal support is by no means the
> > only issue for people who want to straddle. But it *is* an issue, and
> > it's incredibly low-hanging fruit with near-zero real-world impact if it
> > is reintroduced.
>
> But the implication of the PEP is that lack of u'' support is a major
> hindrance
> to porting, justifying the production of the PEP and this discussion. And it's
> not low-hanging fruit with near-zero real-world impact if we're going to
> deprecate it at some point (which Guido was talking about) - you're just
> moving
> the pain to a later date, unless we don't ever deprecate.
I personally see no need to deprecate. I can't conceive of an actual
downside to eternal backwards compatibility here. All the arguments for
its omission presume that there's some enormous untapped market full of
people yearning for its omission who would be either horrified to see
u'' or whom would not understand it on some fundamental level. I don't
think such a market actually exists. However, there *is* a huge market
for people who already understand it instinctively.
> I feel, like some others, that 'xxx' is natural for text, u'xxx' is inelegant
> by
> comparison, and u('xxx') a little more inelegant still.
Yes, the aesthetics argument seems to be the remaining argument. I have
no problem with the aesthetics of u'' myself. But I have no problem
with the aesthetics of u('') for that matter either; if it had been used
as the prevailing style to declare something being text in Python 2 and
it had been omitted I'd be arguing for that instead. But it wasn't, of
course.
Anyway. I think I'm done doing the respond-point-for-point thing; it's
becoming diminishing returns.
- C
___
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 414 - Unicode Literals for Python 3
Armin Ronacher active-4.com> writes: > On 2/27/12 9:36 PM, Antoine Pitrou wrote: > > You don't want to be 3.2-compatible? > See the PEP. It shows how it would still be 3.2 compatible at > installation time due to an installation hook that would be provided. I thought Antoine was just responding to the fact that Ethan's comment didn't mention 3.2. Re. the installation hook, let me get this right. If I have to work with code that needs to run under 3.2 or earlier *and* 3.3, and say that because this PEP has been accepted, the code contains both u'xxx' and 'yyy' forms of Unicode literal, then I can't just edit-save-test, right? I have to run your hook every time I want to switch between testing with 3.3 and 3.2 (say). Isn't this exactly the same problem as with running 2to3, except that your hook might run faster? I'm not convinced you can guarantee a seamless testing experience ;-) Regards, Vinay Sajip ___ 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 414 - Unicode Literals for Python 3
On Mon, 27 Feb 2012 16:10:25 -0500, Chris McDonough wrote: > On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote: > > On 27 February 2012 20:39, Chris McDonough wrote: > > > Note that u'' literals are sort of the tip of the iceberg here; > > > supporting them will obviously not make development under the subset an > > > order of magnitude less sucky, just a tiny little bit less sucky. There > > > are other extremely annoying things, like str(bytes) returning the repr > > > of a bytestring on Python 3. That's almost as irritating as the absence > > > of u'' literals, but we have to evaluate one thing at a time. > > > > So. Am I misunderstanding here, or are you suggesting that this > > particular PEP doesn't help you much, but if it's accepted, it > > represents "the thin end of the wedge" for a series of subsequent PEPs > > suggesting fixes for a number of other "extremely annoying things"...? > > > > I'm sure that's not what you meant, but it's certainly what it sounded > > like to me! > > I'm way too lazy. The political wrangling is just too draining > (especially over something so trivial). But I will definitely support > other proposals that make it easier to straddle, sure. "tip of the iceberg", eh? Or the nose of the camel in the tent. This pushes me in the direction of a -1 vote. --David ___ 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 414 - Unicode Literals for Python 3
Indeed, the wrangling has gone too far already. I'm accepting the PEP. It's about as harmless as they come. Make it so. --Guido van Rossum (sent from Android phone) On Feb 27, 2012 1:12 PM, "Chris McDonough" wrote: > On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote: > > On 27 February 2012 20:39, Chris McDonough wrote: > > > Note that u'' literals are sort of the tip of the iceberg here; > > > supporting them will obviously not make development under the subset an > > > order of magnitude less sucky, just a tiny little bit less sucky. > There > > > are other extremely annoying things, like str(bytes) returning the repr > > > of a bytestring on Python 3. That's almost as irritating as the > absence > > > of u'' literals, but we have to evaluate one thing at a time. > > > > So. Am I misunderstanding here, or are you suggesting that this > > particular PEP doesn't help you much, but if it's accepted, it > > represents "the thin end of the wedge" for a series of subsequent PEPs > > suggesting fixes for a number of other "extremely annoying things"...? > > > > I'm sure that's not what you meant, but it's certainly what it sounded > > like to me! > > I'm way too lazy. The political wrangling is just too draining > (especially over something so trivial). But I will definitely support > other proposals that make it easier to straddle, sure. > > - C > > > ___ > 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/guido%40python.org > ___ 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 414 - Unicode Literals for Python 3
Well said Antoine. --Guido van Rossum (sent from Android phone) On Feb 27, 2012 2:03 PM, "Antoine Pitrou" wrote: > On Mon, 27 Feb 2012 16:54:51 -0500 > Terry Reedy wrote: > > On 2/27/2012 1:17 PM, Guido van Rossum wrote: > > > > >> I just don't understand the pushback here at all. This is such a > > >> nobrainer. > > > > > I agree. Just let's start deprecating it too, so that once Python 2.x > > > compatibility is no longer relevant we can eventually stop supporting > > > it (though that may have to wait until Python 4...). We need to send > > > *some* sort of signal that this is a compatibility hack and that no > > > new code should use it. Maybe a SilentDeprecationWarning? > > > > Before we make this change, I would like to know if this is Armin's last > > proposal to revert Python 3 toward Python 2 or merely the first in a > > series. I question this because last December Armin wrote > > > > "And in my absolutely personal opinion Python 3.3/3.4 should be more > > like Python 2* and Python 2.8 should happen and be a bit more like > > Python 3." > > * he wrote '3' but obviously means '2'. > > http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/ > > > > Chris has also made it clear that he (also?) would like more reversions. > > Please. While I'm not strongly in favour of the PEP, this kind of > argument is dishonest. Whatever Armin's secret wishes may be, his PEP > should be judged on its own grounds. > > Thank you > > Antoine. > > > ___ > 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/guido%40python.org > ___ 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 414 - Unicode Literals for Python 3
Hi, On 2/27/12 9:54 PM, Terry Reedy wrote: > Before we make this change, I would like to know if this is Armin's last > proposal to revert Python 3 toward Python 2 or merely the first in a > series. I question this because last December Armin wrote You're saying as if providing a sane upgrade path was a bad thing. That said, if I had other proposals I would have submitted them *now* since waiting for another Python version to go by would not be helpful. I only have myself to blame for providing that PEP now instead of earlier which would have been a lot more useful. Regards, Armin ___ 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 414 - Unicode Literals for Python 3
Hi, On 2/27/12 9:58 PM, R. David Murray wrote: > But the PEP doesn't address the unicode_literals plus str() approach. > That is, the rationale currently makes a false claim. Which would be exactly what that u() does not do? Regards, Armin ___ 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 414
On 2/27/2012 10:44 AM, Armin Ronacher wrote: On 2/27/12 1:55 AM, Terry Reedy wrote: I presume such a hook would simply remove 'u' prefixes and would run *much* faster than 2to3. If such a hook is satisfactory for 3.2, why would it not be satisfactory for 3.3? Agile development and unittests. Given that last December you wrote "And in my absolutely personal opinion Python 3.3/3.4 should be more like Python 2* and Python 2.8 should happen and be a bit more like Python 3." * you wrote '3' but obviously must have meant '2'. http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/ I would like to know if you think that this one change is enough to do agile development and testing, etc, or whether, as Chris McDonough hopes, this is just the first of a series of proposals you have planned. -- Terry Jan Reedy ___ 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 414 - Unicode Literals for Python 3
On 2/27/2012 4:10 PM, Chris McDonough wrote: On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote: On 27 February 2012 20:39, Chris McDonough wrote: Note that u'' literals are sort of the tip of the iceberg here; supporting them will obviously not make development under the subset an order of magnitude less sucky, just a tiny little bit less sucky. There are other extremely annoying things, like str(bytes) returning the repr of a bytestring on Python 3. That's almost as irritating as the absence of u'' literals, but we have to evaluate one thing at a time. So. Am I misunderstanding here, or are you suggesting that this particular PEP doesn't help you much, but if it's accepted, it represents "the thin end of the wedge" for a series of subsequent PEPs suggesting fixes for a number of other "extremely annoying things"...? Last December, Armin wrote "And in my absolutely personal opinion Python 3.3/3.4 should be more like Python 2* and Python 2.8 should happen and be a bit more like Python 3." * he wrote '3' but obviously means '2'. http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/ I'm sure that's not what you meant, but it's certainly what it sounded like to me! I'm way too lazy. The political wrangling is just too draining (especially over something so trivial). Turning Python 3 back into Python 2, or even moving in that direction, is neither 'trivial' nor a 'no-brainer'. > But I will definitely support other proposals that make it easier to straddle, sure. -- Terry Jan Reedy ___ 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 414 - Unicode Literals for Python 3
On Feb 27, 2012, at 09:43 PM, Vinay Sajip wrote:
>Well, according to the approach I described above, that one thing needs to be
>the present 3.x syntax - 'xxx' is text, b'xxx' is bytes, and f('xxx') is
>native string (or whatever name you want instead of f). With the
>unicode_literals import, that syntax works on 2.6+ and 3.2+, so ISTM it
>should work within the constraints you mentioned for your software.
I agree, this works for me and it's what I do in all my code now. Strings
adorned with u-prefixes just look unnatural, and there's no confusion that
unadorned strings mean "unicode". And yes, I have had to use str('')
occasionally to mean "native strings", but it's so rare and constant cost that
I didn't even think twice about it after I discovered this trick.
But it seems like this is just not an acceptable solution for proponents of
the PEP. Given that the above is the most generally accepted way to spell
these things in the Python versions we care about today (>= 2.6, 3.2), at the
very least, the PEP needs to be rewritten to make it clear why the above is
unacceptable. That's the only way IMO that the PEP can be judged on its own
merits.
(I'll concede for the sake of argument that 2to3 is unacceptable. I also
think it's unnecessary though.)
Cheers,
-Barry
___
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 414 - Unicode Literals for Python 3
On Feb 27, 2012, at 02:06 PM, Guido van Rossum wrote: >Indeed, the wrangling has gone too far already. I'm accepting the PEP. It's >about as harmless as they come. Make it so. I've learned that once a PEP is pronounced upon, it's usually to my personal (if not all of our mutual :) benefit to stop arguing. I still urge the PEP author to clean up the PEP and specifically address the issues brought up in this thread. That will be useful for the historical record. -Barry ___ 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 414 - Unicode Literals for Python 3
Hi, On 2/27/12 10:29 PM, Barry Warsaw wrote: > I still urge the PEP author to clean up the PEP and specifically address the > issues brought up in this thread. That will be useful for the historical > record. That is a given. Regards, Armin ___ 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 414 - Unicode Literals for Python 3
28.02.12 00:11, Armin Ronacher написав(ла): On 2/27/12 9:58 PM, R. David Murray wrote: But the PEP doesn't address the unicode_literals plus str() approach. That is, the rationale currently makes a false claim. Which would be exactly what that u() does not do? No. 1. u() is trivial for Python 3 and relatively expensive (and doubtful for non-ascii literals) for Python 2, unicode_literals plus str() is trivial for Python 3 and cheap for Python 2. 2. Text strings are natural and prevalent, but "natural" strings are domain-specific and archaic. ___ 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 414
Hi, On 2/27/12 10:18 PM, Terry Reedy wrote: > I would like to know if you think that this one change is enough to do > agile development and testing, etc, or whether, as Chris McDonough > hopes, this is just the first of a series of proposals you have planned. Indeed I have three other PEPs in the work. The reintroduction of "except (((ExceptionType),),)", the "<>" comparision operator and the removal of "nonlocal", the latter to make Python 2.x developers feel better about themselves. :-) Regards, Armin ___ 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] Add a frozendict builtin type
In http://mail.python.org/pipermail/python-dev/2012-February/116955.html Victor Stinner proposed: > The blacklist implementation has a major issue: it is still possible > to call write methods of the dict class (e.g. dict.set(my_frozendict, > key, value)). It is also possible to use ctypes and violate even more invariants. For most purposes, this falls under "consenting adults". > The whitelist implementation has an issue: frozendict and dict are not > "compatible", dict is not a subclass of frozendict (and frozendict is > not a subclass of dict). And because of Liskov substitutability, they shouldn't be; they should be sibling children of a basedict that doesn't have the the mutating methods, but also doesn't *promise* not to mutate. > * frozendict values must be immutable, as dict keys Why? That may be useful, but an immutable dict whose values might mutate is also useful; by forcing that choice, it starts to feel too specialized for a builtin. > * Add an hash field to the PyDictObject structure That is another indication that it should really be a sibling class; most of the uses I have had for immutable dicts still didn't need hashing. It might be a worth adding anyhow, but only to immutable dicts -- not to every instance dict or keywords parameter. > * frozendict.__hash__ computes hash(frozenset(self.items())) and > caches the result is its private hash attribute Why? hash(frozenset(selk.keys())) would still meet the hash contract, but it would be approximately twice as fast, and I can think of only one case where it wouldn't work just as well. (That case is wanting to store a dict of alternative configuration dicts (with no defaulting of values), but ALSO wanting to use the configurations themselves (as opposed to their names) as the dict keys.) -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ 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 414
On Feb 27, 2012, at 10:38 PM, Armin Ronacher wrote: >Indeed I have three other PEPs in the work. The reintroduction of >"except (((ExceptionType),),)", the "<>" comparision operator and the >removal of "nonlocal", the latter to make Python 2.x developers feel >better about themselves. :-) One of them's a winner in my book, but I'll let you guess which one. OTOH, the time machine can bring you back to the future again. -Barry ___ 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 414
28.02.12 00:52, Barry Warsaw написав(ла): On Feb 27, 2012, at 10:38 PM, Armin Ronacher wrote: Indeed I have three other PEPs in the work. The reintroduction of "except (((ExceptionType),),)", the"<>" comparision operator and the removal of "nonlocal", the latter to make Python 2.x developers feel better about themselves. :-) One of them's a winner in my book, but I'll let you guess which one. OTOH, the time machine can bring you back to the future again. http://www.artima.com/weblogs/viewpost.jsp?thread=173477 ___ 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 414 - Unicode Literals for Python 3
On 2/27/2012 4:56 PM, Jim J. Jewett wrote: In http://mail.python.org/pipermail/python-dev/2012-February/116953.html Terry J. Reedy wrote: I presume that most 2.6 code has problems other than u'' when attempting to run under 3.x. Why? Since writing the above, I realized that the following is a realistic scenario. 2.6 or 2.7 code a) uses has/set/getattr, so unicode literals would require a change; b) uses non-ascii chars in unicode literals; c) uses (or could be converted to use) print as a function; and d) otherwise uses a common 2-3 subset. Such would only need the u prefix addition to run under both Pythons. This works the other way, of course, for backporting code. So I am replacing 'most' with 'some unknown-to-me fraction' ;-). -- Terry Jan Reedy ___ 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 414 - Unicode Literals for Python 3
Armin Ronacher active-4.com> writes: > > Hi, > > On 2/27/12 10:29 PM, Barry Warsaw wrote: > > I still urge the PEP author to clean up the PEP and specifically address the > > issues brought up in this thread. That will be useful for the historical > > record. > That is a given. Great. My particular interest is w.r.t. the installation hook for 3.2 and the workflow for testing code in 3.2 and 3.3 at the same time. Regards, Vinay Sajip ___ 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
>> The blacklist implementation has a major issue: it is still possible >> to call write methods of the dict class (e.g. dict.set(my_frozendict, >> key, value)). > > It is also possible to use ctypes and violate even more invariants. > For most purposes, this falls under "consenting adults". My primary usage of frozendict would be pysandbox, a security module. Attackers are not consenting adults :-) Read-only dict would also help optimization, in the CPython peephole or the PyPy JIT. In pysandbox, I'm trying to replace __builtins_ and (maybe also type.__dict__) by a frozendict. These objects rely on PyDict API and so expect a type "compatible" with dict. But PyDict_GetItem() and PyDict_SetItem() may use a test like isinstance(obj, (dict, frozendict)), especially if the C strucure is "compatible". But pysandbox should not drive the design of frozendict :-) >> The whitelist implementation has an issue: frozendict and dict are not >> "compatible", dict is not a subclass of frozendict (and frozendict is >> not a subclass of dict). > > And because of Liskov substitutability, they shouldn't be; they should > be sibling children of a basedict that doesn't have the the mutating > methods, but also doesn't *promise* not to mutate. As I wrote, I realized that it doesn't matter if dict doesn't inherit from frozendict. >> * frozendict values must be immutable, as dict keys > > Why? That may be useful, but an immutable dict whose values > might mutate is also useful; by forcing that choice, it starts > to feel too specialized for a builtin. If values are mutables, the frozendict cannot be called "immutable". tuple and frozenset can only contain immutables values. All implementations of frozendict that I found expect frozendict to be hashable. >> * frozendict.__hash__ computes hash(frozenset(self.items())) and >> caches the result is its private hash attribute > > Why? hash(frozenset(selk.keys())) would still meet the hash contract, > but it would be approximately twice as fast, and I can think of only > one case where it wouldn't work just as well. Yes, it would faster but the hash is usually the hash of the whole object content. E.g. the hash of a tuple is not the hash of items with odd index, whereas such hash function would also meet the "hash contract". All implementations of frozendict that I found all use items, and not only values or only keys. Victor ___ 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 414 - Unicode Literals for Python 3
Antoine Pitrou wrote:
On Mon, 27 Feb 2012 13:09:24 -0800
Ethan Furman wrote:
Martin v. Löwis wrote:
Eh? The 2.6 version would also be u('that'). That's the whole point
of the idiom. You'll need a better counter argument than that.
So the idea is to convert the existing 2.6 code to use parenthesis as
well? (I obviously haven't read the PEP -- my apologies.)
Well, if you didn't, you wouldn't have the same sources on 2.x and 3.x.
And if that was ok, you wouldn't need the u() function in 3.x at all,
since plain string literals are *already* unicode strings there.
True -- but I would rather have u'' in 2.6 and 3.3 than u('') in 2.6 and
3.3.
You don't want to be 3.2-compatible?
Unfortunately I do. However, at some point 3.2 will fall off the edge
of the earth and then u'' will be just fine.
This is probably a dumb question, but why can't we add u'' back to 3.2?
It seems an incredibly minor change, and we are not in security-only
fix stage, are we?
~Ethan~
___
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 414 - Unicode Literals for Python 3
On Mon, Feb 27, 2012 at 17:15, Ethan Furman wrote: > This is probably a dumb question, but why can't we add u'' back to 3.2? It > seems an incredibly minor change, and we are not in security-only fix stage, > are we? We don't add features to bug-fix releases. ___ 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2012 06:34 PM, Victor Stinner wrote:
> tuple and frozenset can only contain immutables values.
Tuples can contain mutables::
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ({},)
({},)
$ python3
Python 3.2 (r32:88445, Mar 10 2011, 10:08:58)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ({},)
({},)
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9MFOAACgkQ+gerLs4ltQ5mjQCgi1U7CloZUy0u0+c0mlLlIuko
+IIAoLqKGcAb6ZAEY5wpkwvtgRa6S+LV
=7Mh5
-END PGP SIGNATURE-
___
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 414 - Unicode Literals for Python 3
Armin Ronacher wrote: Hi, On 2/27/12 4:44 PM, mar...@v.loewis.de wrote: Maybe I'm missing something, but there doesn't seem to be a benchmark that measures the 2to3 performance, supporting the claim that it runs "two orders of magnitude" slower (which I'd interpret as a factor of 100). My Jinja2+Werkzeug's testsuite combined takes 2 seconds to run (Werkzeug actually takes 3 because it pauses for two seconds in a cache expiration test). 2to3 takes 45 seconds to run. And those are small code bases (15K lines combined). It's not exactly two orders of magnitude so I will probably change the writing to "just" 20 times slower but it illustrates the point. That would be one order of magnitude. -- Steven ___ 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 414 - Unicode Literals for Python 3
On 2/27/12 9:58 PM, R. David Murray wrote: But the PEP doesn't address the unicode_literals plus str() approach. That is, the rationale currently makes a false claim. Which would be exactly what that u() does not do? Armin, I propose that you correct the *factual* deficits of the PEP (i.e. remove all claims that cannot be supported by facts, or are otherwise incorrect or misleading). Many readers here would be more open to accepting the PEP if it was factual rather than polemic. The PEP author is supposed to collect all arguments, even the ones he doesn't agree with, and refute them. In this specific issue, the PEP states "the unicode_literals import the native string type is no longer available and has to be incorrectly labeled as bytestring" This is incorrect: even though the native string type indeed is no longer available, it is *not* consequential that it has to be labeled as byte string. Instead, you can use the str() function. It may be that you don't like that solution for some reason. If so, please mention the approach in the PEP, along with your reason for not liking it. Regards, Martin ___ 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] Marking packaging-related PEPs as Finished after fixing some bugs in them
Terry Reedy wrote: On 2/27/2012 6:50 AM, Antoine Pitrou wrote: 'rc' makes sense to most people while 'c' is generally unheard of. 'rc' following 'a' and 'b' only makes sense to people who are used to it and know what it means. 'c' for 'candidate' makes more sense to me both a decade ago and now. 'rc' is inconsistent. Why not 'ra' for 'release alpha' or 'ar' for 'alpha release'? In other words, all releases are releases, so why not be consistent and either always or never include 'r'? (Never would be better since always is redundant.) I suspect many non-developer users find 'rc' as surprising as I did. Yes, but you should only find it surprising *once*, the first time you learn about the standard release schedule: pre-alpha alpha beta release candidate production release http://en.wikipedia.org/wiki/Software_release_life_cycle Not all releases are equivalent. In English, we can not only verbify nouns, but we can also nounify verbs. So, yes, any software which is released is *a* release; but only the last, production-ready release is *the* release. The others are pre-release releases. Ain't English grand? If if you prefer a more wordy but slightly less confusing way of saying it, they are pre-release versions which have been released. This reply of mine on the python-list list may also be relevant: http://mail.python.org/pipermail/python-list/2012-February/1288569.html -- Steven ___ 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 414 - Unicode Literals for Python 3
Brian Curtin wrote: On Mon, Feb 27, 2012 at 17:15, Ethan Furman wrote: This is probably a dumb question, but why can't we add u'' back to 3.2? It seems an incredibly minor change, and we are not in security-only fix stage, are we? We don't add features to bug-fix releases. Ah. Well that's easy then! Call it a bug! ;) ~Ethan~ ___ 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 Tue, Feb 28, 2012 at 9:34 AM, Victor Stinner
wrote:
>>> The blacklist implementation has a major issue: it is still possible
>>> to call write methods of the dict class (e.g. dict.set(my_frozendict,
>>> key, value)).
>>
>> It is also possible to use ctypes and violate even more invariants.
>> For most purposes, this falls under "consenting adults".
>
> My primary usage of frozendict would be pysandbox, a security module.
> Attackers are not consenting adults :-)
>
> Read-only dict would also help optimization, in the CPython peephole
> or the PyPy JIT.
I'm pretty sure the PyPy jit can already pick up and optimise cases
where a dict goes "read-only" (i.e. stops being modified).
I think you need to elaborate on your use cases further, and explain
what *additional* changes would be needed, such as allowing frozendict
instances as __dict__ attributes in order to create truly immutable
objects in pure Python code.
In fact, that may be a better way to pitch the entire PEP. In current
Python, you *can't* create a truly immutable object without dropping
down to a C extension:
>>> from decimal import Decimal
>>> x = Decimal(1)
>>> x
Decimal('1')
>>> hash(x)
1
>>> x._exp = 10
>>> x
Decimal('1E+10')
>>> hash(x)
100
Contrast that with the behaviour of a float instance:
>>> 1.0.imag = 1
Traceback (most recent call last):
File "", line 1, in
AttributeError: attribute 'imag' of 'float' objects is not writable
Yes, it's arguably covered by the "consenting adults" rule, but
really, Decimal instances should be just as immutable as int and float
instances. The only reason they aren't is that it's hard enough to set
it up in Python code that the Decimal implementation settles for "near
enough is good enough" and just uses __slots__ to prevent addition of
new attributes, but doesn't introduce the overhead of custom
__setattr__ and __delattr__ implementations to actively *prevent*
modifications.
We don't even need a new container type, we really just need an easy
way to tell the __setattr__ and __delattr__ descriptors for
"__slots__" that the instance initialisation is complete and further
modifications should be disallowed.
For example, if Decimal.__new__ could call "self.__lock_slots__()" at
the end to set a flag on the instance object, then the slot
descriptors could read that new flag and trigger an error:
>>> x._exp = 10
Traceback (most recent call last):
File "", line 1, in
AttributeError: attribute '_exp' of 'Decimal' objects is not writable
To be clear, all of this is currently *possible* if you use custom
descriptors (such as a property() implementation where setattr and
delattr look for such a flag) or override __setattr__/__delattr__.
However, for a micro-optimised type like Decimal, that's a hard choice
to be asked to make (and the current implementation came down on the
side of speed over enforcing correctness). Given that using __slots__
in the first place is, in and of itself, a micro-optimisation, I
suspect Decimal is far from the only "immutable" type implemented in
pure Python that finds itself having to make that trade-off. (An extra
boolean check in C is a *good* trade-off of speed for correctness.
Python level descriptor implementations or attribute access overrides,
on the other hand... not so much).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
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
Nick Coghlan gmail.com> writes: > I'm pretty sure the PyPy jit can already pick up and optimise cases > where a dict goes "read-only" (i.e. stops being modified). No, it doesn't. We handle cases like a type's dict, or a module's dict, by having them use a different internal implementation (while, of course, still being dicts at the Python level). We do *not* handle the case of trying to figure out whether a Python object is immutable in any way. Alex ___ 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 414 - Unicode Literals for Python 3
On Tue, Feb 28, 2012 at 9:19 AM, Terry Reedy wrote:
> Since writing the above, I realized that the following is a realistic
> scenario. 2.6 or 2.7 code a) uses has/set/getattr, so unicode literals would
> require a change; b) uses non-ascii chars in unicode literals; c) uses (or
> could be converted to use) print as a function; and d) otherwise uses a
> common 2-3 subset. Such would only need the u prefix addition to run under
> both Pythons. This works the other way, of course, for backporting code. So
> I am replacing 'most' with 'some unknown-to-me fraction' ;-).
Yep, that's exactly the situation I'm in with PulpDist (a web app that
primarily targets deployment on RHEL 6, which means Python 2.6). Since
I preformat all my print output with either str.format or str.join (or
use the logging module) and always use "except exc as var" to catch
exceptions, the natural way to write Python 2 code for me is *almost*
source compatible with Python 3. The only big discrepancy I'm
currently aware of? Unicode literals.
Now, I could retrofit the entire code base with the unicode_literals
import and str("") for native strings, but that has problems of its
own:
- it doesn't match the Pulp upstream, so it would make it harder for
them to review my plugins and client API usage code (or integrate them
into the default plugin set or client support API if they decide they
like them). Given that I'm one of the guinea pigs for experimental
Pulp APIs and have to dive into *their* code on occasion, it would
also be a challenge for *me* to switch modes when debugging .
- it doesn't match Django (at least, not in 1.3, which is the version
I'm using) (another potential annoyance when debugging)
- it doesn't match any of the other Django applications I use (once
again, debugging may lead to me looking at this code)
- it doesn't match the standard library (yep, you guessed it, I'd have
to mode switch when looking at standard library code, too)
- it doesn't match the intuitions of current Python 2 developers that
aren't up to speed with the niceties of Python 3 porting
Basically, using the unicode_literals import would significantly raise
the barrier to entry for PulpDist *as a Python 2 project*, as well as
forcing me to switch mental models for text processing whenever I have
to look at the code in a dependency during a debugging session.
Therefore, given that Python 2 will be my primary target for the
immediate future (and any collaborators are likely to be RHEL 6 and
hence Python 2 focused), I don't want to use that particular future
import. The downside of that choice (currently) is that it kills any
possibility of running any of it on Python 3, even the command line
client or the web front end after Django gets ported. With explicit
unicode literals being restored in Python 3.3, though, I'm a lot more
optimistic about the feasibility of porting it without too much effort
(as well as the prospect of other Django app dependencies gaining
Python 3 support).
In terms of third party upstreams, python 3 compatibility patches that
affect *every single string literal in the entire project* (either
directly or converting the entire project to the "unicode_literals"
import) aren't likely to even get reviewed, let alone accepted. By
contrast (for a project that already only supports 2.6+), cleaning up
print statements and exception handling should be a much smaller patch
that is easy to both review and accept. Making it as easy as possible
for maintainers that don't really care about Python 3 to accept
patches from people that *do* care is a very good thing.
There are still other problems that are going to affect the folks
playing at the wire protocol level, but the lack of unicode literals
is a big one that affects the entire application stack.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
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 414 - Unicode Literals for Python 3
On Mon, 27 Feb 2012 22:11:36 +, Armin Ronacher
wrote:
> On 2/27/12 9:58 PM, R. David Murray wrote:
> > But the PEP doesn't address the unicode_literals plus str() approach.
> > That is, the rationale currently makes a false claim.
> Which would be exactly what that u() does not do?
The rationale claims there's no way to spell "native string" if you use
unicode_literals, which is not true.
It would be different from u('') in that I would expect that there are
far fewer instances where 'native string' is required than there are
places where unicode strings work (and should therefore be preferred).
This only matters now in order to make the PEP more accurate, but I
think that is a good thing to do.
--David
___
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 414 - Unicode Literals for Python 3
R. David Murray bitdance.com> writes:
> The rationale claims there's no way to spell "native string" if you use
> unicode_literals, which is not true.
>
> It would be different from u('') in that I would expect that there are
> far fewer instances where 'native string' is required than there are
> places where unicode strings work (and should therefore be preferred).
A couple of people have said that 'native string' is spelt 'str', but I'm not
sure that's the right answer. For example, 2.x's cString.StringIO expects native
strings, not Unicode:
>>> from cStringIO import StringIO
>>> s = StringIO(u'\xe9')
>>> s
>>> s.getvalue()
'\xe9\x00\x00\x00'
Of course, you can't call str() on that value to get a native string:
>>> str(u'\xe9')
Traceback (most recent call last):
File "", line 1, in
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 0:
ordinal not in range(128)
So I think using str will not give the desired effect in some situations: on
Django, I used a function that resolves differently depending on Python version:
something like
def native(literal): return literal
on Python 3, and
def native(literal): return literal.encode('utf-8')
on Python 2.
I'm not saying this is the right thing to do for all cases - just that str() may
not be, either. This should be elaborated in the PEP.
Regards,
Vinay Sajip
___
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
