Hi,
> Am 21.06.2012 12:23, schrieb Armin Ronacher:
> Does the code handle a chain of absolute and relative symlinks
> correctly, for example a relative symlink that points to another
> relative symlink in a different directory that points to a file in a
> third directry?
No, bu
Due to an user error on my part I was not using os.readlink correctly.
Since links can be relative to their location I think it would make sense
to provide an os.path.resolve helper that automatically returns the
absolute path:
def resolve(filename):
try:
target = os.readl
Hi,
On 3/3/12 2:28 AM, Vinay Sajip wrote:
> So, looking at a large project in a relevant problem domain, unicode_literals
> and native string markers would appear not to adversely impact readability or
> performance.
What are you trying to argue? That the overall Django testsuite does
not do a lo
Hi,
On 3/4/12 9:00 PM, Vinay Sajip wrote:
> I realise that the implementation is different, using tokenize rather than
> lib2to3, but in terms of its effect on the transformed code, what are the
> differences between this hook and running 2to3 with just the fix_unicode
> fixer?
I would hope they
Hi,
On 3/4/12 4:44 PM, Guido van Rossum wrote:
> I'd love a pointer to the rubygems debacle...
Setuptools worked because Python had .pth files for a long, long time.
When the Ruby world started moving packages into nonstandard locations
(GameName/) something needed to activate that
import machiner
Hi,
Jut to reiterate what I wrote on IRC:
Please do not write or advocate for import hooks, especially not for
porting purposes. It would either mean that people start adding that
hook on their own to the code (and that awfully reminds me of the days
of 'require "rubygems"' in the Ruby world) or
Hi,
On 3/4/12 2:01 PM, Nick Coghlan wrote:
> Nice :)
>
> Do you have any more updates left to do? I saw the change, the tests,
> the docs and the tokenizer updates go by on python-checkins, so if
> you're done we can mark the PEP as Final (at which point the inclusion
> in the first alpha is impl
Hi,
It should also be added that the Python 3.3 alpha will release with support:
Python 3.3.0a0 (default:042e7481c7b4, Mar 4 2012, 12:37:26)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> u"Hello" + ' World!'
Hi,
On 3/1/12 10:38 PM, Yury Selivanov wrote:
> Sorry if I sounded like 'attacking' you. I certainly had no such
> intention, as I believe nobody on this list.
Sorry if I sound cranky but I got that impression from the responses
here (which are greatly different from the responses I got on other
Hi,
On 2/29/12 12:30 PM, Yury Selivanov wrote:
> I see you've (or somebody) changed:
Yes, I reworded that.
> Could you just remove the statement completely?
I will let Nick handle the PEP wording.
> I don't think that PEPs are the right place to put such polemic
> and biased statements.
Why cal
Hi,
On 2/27/12 11:54 PM, Steven D'Aprano wrote:
> That would be one order of magnitude.
I am aware of that :-)
Regards,
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
Hi,
On 2/28/12 12:16 AM, mar...@v.loewis.de wrote:
> 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 f
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 t
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
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-De
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 pa
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-De
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 mail
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 test
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 tes
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
n
Hi,
On 2/26/12 5:45 PM, Antoine Pitrou wrote:
>> The automatic upgrading of binary strings to unicode strings that
>> would be enabled by this proposal would make it much easier to port
>> such libraries over.
>
> What "automatic upgrading" is that talking about?
The word "upgrade" is probably so
Hi,
On 2/26/12 12:42 PM, Vinay Sajip wrote:
> When this came up earlier (when I think Chris McDonough raised it) the issue
> of
> what to do on 3.2 came up, and though it has been addressed somewhat in the
> PEP,
> it would be nice to see the suggested on-installation hook fleshed out a
> littl
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
Hi,
On 2/26/12 12:34 PM, Ned Batchelder wrote:
> There are already __future__ imports that violate this principle: from
> __future__ import division. That doesn't mean I'm in favor of this new
> __future__, just keeping a wide angle on the viewfinder.
That's actually mentioned in the PEP :-)
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.
Re
Hi,
Something I should add to this now that I thought about it a bit more:
Assuming this should be fixed on a language level the solution would
probably be to salt hashes. The most common hash to salt here is the
PyUnicode hash for obvious reasons.
- Option a: Compiled in Salt
+ Easy to imple
Hi,
Just some extra thoughts about the whole topic in the light of web
applications (since this was hinted in the talk) running on Python:
Yes, you can limit the number of maximum allowed parameters for post
data but really there are so many places where data is parsed into
hashing conta
Hi,
On 3/16/11 3:48 AM, Antoine Pitrou wrote:
I may be mistaken, but you seem to conflate two things: encoding of
file names, and encoding of file contents. I guess that virtualenv
chokes on the file contents, but most of your argument seems related to
encoding of file names (aka "filesystem enc
Hi everybody,
We (me and Carl Meyer) did some experimentation with encoding behavior
on Python 3. Carl did some hacking on getting virtualenv running on
Python 3 and it turned out that his version of virtualenv did not work
on Python 3 on my server either. So none of the virtulenv installati
Hi,
Guido van Rossum python.org> writes:
> Anyway, it seems the collections module in particular is already
> internally inconsistent -- NamedTuple vs. defaultdict. In a sense
> defaultdict is the odd one out here, since these are things you import
> from some module, they're not built-in. Maybe
Hi,
Raymond Hettinger rcn.com> writes:
> When we use the class, we typically only spell-out the constructor
> once while actually using the returned
> object many times. So,
> have we really saved any typing?
I'm fine with the typed out name as well, but I still would prefer lowercase to
stay c
Steve Holden holdenweb.com> writes:
> Surely that's just a thinko in the subject line? The PEP specifies
> "ordered dictionary" and nobody has been talking about "directories".
Actually, the initial version of the PEP had that typo in the topic. Guess I
copy pasted wrong again:
http://www.goog
Guido van Rossum python.org> writes:
> +1 for odict. Somehow I thought that was the name proposed by the PEP.
It originally was, Raymond wanted to change it. I would still vote for odict if
that's still possible :)
Regards,
Armin
___
Python-Dev mai
Hi,
Georg Brandl gmx.net> writes:
> We're already quite inconsistent with type name casing in the collections
> module, so it wouldn't matter so much. (Though I'd find symmetry with
> defaultdict pleasing as well.)
We either have the way to be consistent with defaultdict and dict or with
Counte
Hi,
Guido van Rossum python.org> writes:
> This sounds fair. Note that dict.__eq__ actually returns
> NotImplemented if not isinstance(other, dict) so you could tighten the
> test to isinstance(other, dict) if you wanted to.
I'm actually very happy with that decision. The original PEP was doing
Hi everybody,
PEP 372 was modified so that it provides a simpler API (only the dict API
to be exact) and it was decided to start with a Python-only implementation
and replace it with a C version later if necessary.
Annotated changes from earlier versions of the PEP:
- the extra API for ordered
Hi,
Adam Olsen gmail.com> writes:
> IMO, this is a deeper problem than suggested. As far as I know,
> python does not (and should not) make promises as to when it'll
> collect object. We should expect weakrefs to be cleared at random
> points, and code defensively.
It doesn't promise when obje
Hi,
Josiah Carlson gmail.com> writes:
> i = list(d.keys())
Obviously that doesn't solve the problem. list() consumes the generator
one after another, objects can still die when the list is created. Imagine
the following example which uses threads::
from time import sleep
from weakref
Hi everybody,
In Python 2.x when iterating over a weak key dictionary for example, the common
idom for doing that was calling dictionary.keys() to ensure that a list of all
objects is returned it was safe to iterate over as a weak reference could stop
existing during dict iteration which of course
Hi,
Benjamin Peterson gmail.com> writes:
> On Sat, Sep 13, 2008 at 4:49 AM, Georg Brandl gmx.net> wrote:
> > If not, I'll remove the traces from the docs, where they only serve to
> > confuse where MacOS X actually belongs under "Unix", not "Mac".
>
> Yes, according to PEP 11, support was remo
Jeff Hall gmail.com> writes:
> reversed(
> seq)
> Return a reverse iterator. seq must be an object which
> supports the sequence protocol (the __len__() method and the __getitem__()
method with integer arguments starting at
> 0). New in version 2.4. the above appears to only be true for lists.
Hi,
I stumbled upon a confusing listreverseiterator behavior:
>>> l = [1, 2, 3, 4]
>>> i = iter(l)
>>> ri = reversed(l)
>>> len(i)
Traceback (most recent call last):
File "", line 1, in
TypeError: object of type 'listiterator' has no len()
>>> len(ri)
4
>>> ri.next()
4
>>> len(ri)
3
This is t
Guido van Rossum python.org> writes:
> The one thing that may be missing from Python is things like
> interpretation of surrogates by functions like isalpha() and I'm okay
> with adding that (since those have to loop over the entire string
> anyway).
That and methods to safely iterate and slice s
Armin Ronacher active-4.com> writes:
>
> There are far more responses for that topic than I imagined so I would love
> to write a PEP about that topic, incorporating the ideas/questions and
> suggestions discussed here.
There is now a PEP for the ordered dict:
- PEP: http:/
Martin v. Löwis v.loewis.de> writes:
>
> > I compared multiple ordered dicts now (including Babel, Django and the
> > C-implementation I mentioned earlier) and implemented a python version
> > of the ordered dict as reference implementation:
> >
> >http://dev.pocoo.org/hg/sandbox/raw-file/t
There are far more responses for that topic than I imagined so I would love
to write a PEP about that topic, incorporating the ideas/questions and
suggestions discussed here.
Regards,
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
Hi,
Alexander Schremmer <2008a usenet.alexanderweb.de> writes:
> Even worse, most of them are slow, i.e. show a wrong algorithmic
> complexity ...
I already said that in the initial post.
> > I have an example implementation here that incorporates the ideas
> > from ordereddict, Django's Ordere
Steven D'Aprano pearwood.info> writes:
> Conceptually, I would expect the following behaviour:
>
> >>> od = odict()
> >>> od[1] = 'spam' # insert a new key
> >>> od[2] = 'parrot' # insert a new key
> >>> od[1] = 'ham' # modify existing key
> >>> od.items()
> [(1, 'ham'), (2, 'parrot')]
That b
Raymond Hettinger rcn.com> writes:
> For an insertion order dictionary, there was also a question about
> how to handle duplicate keys.
>
> Given odict([(k1,v1), (k2,v2), (k1,v3)]), what should the odict.items()
> return?
>
>[(k1,v3), (k2,v2)]
>[(k2,v2), (k1,v3)]
All the ordered dict i
Hasan Diwan gmail.com> writes:
>
> 2008/6/14 Talin acm.org>:
> > There's been a lot of controversy/confusion about ordered dicts. One of the
> > sources of confusion is that people mean different things when they use the
> > term "ordered dict": In some cases, the term is used to mean a diction
BJörn Lindqvist gmail.com> writes:
> I think that the name ordereddict would be more readable though, and
> match the existing defaultdict class in the collections module.
While I agree that "ordered" makes more sense, it's pretty stupid to type
with two 'd's right after another.
Regards,
Armin
Guido van Rossum python.org> writes:
>
> On Sat, Jun 14, 2008 at 4:57 PM, André Malo perlig.de> wrote:
> > I find this collection of cases pretty weak as an argument for implementing
> > that in the stdlib. A lot of special purpose types would fit into such
> > reasoning, but do you want to hav
Hi,
I noticed lately that quite a few projects are implementing their own
subclasses of `dict` that retain the order of the key/value pairs.
However half of the implementations I came across are not implementing
the whole dict interface which leads to weird bugs, also the performance
of a Python i
Hi,
That's just a flaming-sword thread but I want to mention it nonetheless :-)
Basically I propose getting rid of __future__._Feature.getMandatoryRelease()
in favour of __future__._Feature.mandatory. That's backwards compatibile
and much more pythonic. Getters/Setters are considered unpythonic
Greg Ewing canterbury.ac.nz> writes:
> Well, I'm skeptical about the whole ABC thing in the
> first place -- it all seems very unpythonic to me.
I think it's very pythonic and the very best solution to interfaces *and*
duck typing. Not only does it extend duck-typing in a very, very cool way
but
Hi,
Georg Brandl gmx.net> writes:
> I'd argue that "find" is more primitive than "split" -- split is intuitively
> implemented using find and slicing, but implementing find using split and
> len is unintuitive. (Of course, "index" can be used instead of "find".)
It surely is, but it would proba
Hi,
Strings are currently iterable and it was stated multiple times that this is a
good idea and shouldn't change. While I still don't think that that's a good
idea I would like to propose a solution for the problem many people are
experiencing by introducing an abstract base class for strings.
Hi,
Guido van Rossum python.org> writes:
> There's no need to register as Sized -- the Sized ABC recognizes
> classes that define __len__ automatically. The Container class does
> the same looking for __contains__. Since the deque class doesn't
> implement __contains__, it is not considered a Co
Hi,
Jeroen Ruigrok van der Werven in-nomine.org> writes:
> Would people object if such functionality got added to urllib?
I would ;-) There are IRIs, just that nobody wrote a useful module for that.
There are algorithms in the RFC that can convert URIs to IRIs and the other way
round. IMO tha
Hi,
Guido van Rossum python.org> writes:
> The staticmethod thing isn't new; that's also the case in 2.x.
staticmethod hasn't changed, method has. In the past Class.method gave
you a unbound method, now you get a function back as if it was a static
method.
> The super() thing is a case of prac
Hi all,
I blogged about that topic today which turned out to be a very bad idea,
so I summarize it for the mailinglist here to hopefully start a discussion
about the topic, which I think is rather important.
In the last weeks something remarkable happened in the Python3 sources:
self kinda became
Hi all,
I would like to propose a new module for the stdlib for Python 2.6
and higher: "ast". The motivation for this module is the pending
deprecation for compiler.ast which is widely used (debugging,
template engines, code coverage etc.). _ast is a very solid module
and is without a doubt eas
Hi all,
I propose a small change on the "from"-import behavior. Currently there are two
ways to import a module name foo from bar. Namely "import foo.bar as bar" and
"from foo import bar". The main problem with the second is that it will not
work in every situation.
Modules are registered wit
Hi,
It's one of those "non issues" but there are still some situations where you
have to deal with Infinity and NaN, even in Python. Basically one the problems
is that the repr of floating point numbers is platform depending and sometimes
yields "nan" which is not evaluable. It's true that eval()
Hoi,
Due to some server issues I had to take the web version down. But expect an
updated version in a few days.
Regards,
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
Hoi,
Dennis Benzinger gmx.net> writes:
> Looks good. But should the source pages really use syntax highlighting?
> I think if somebody is interested in the source then they should get
> the real source without any highlighting. If you decide to keep the
> syntax highlighting then the highlightin
Hoi,
Additionally to the offline docs that Georg published some days ago there is
also a web version which currently looks and works pretty much like the offline
version. There are however some differences that are worth knowing:
- Cleaner URLs. You can actually guess them because we took the ide
Hoi,
Georg Brandl gmx.net> writes:
> Who's documenting a scripting language?
Wanted to say agile :D
Regards,
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
Hoi,
Martin Blais furius.ca> writes:
> About possibilities: I'm sorry but that is simply not true. LaTeX
> provides the full power of macro expansion, while ReST is a fixed
> (almost, roles are an exception) syntax which has its own set of
> problems and ambiguities.
I was speaking of rst in co
Hoi,
Stephen J. Turnbull xemacs.org> writes:
>
> IMO that pair of examples shows clearly that, in this application,
> reST is not an improvement over LaTeX in terms of readability/
> writability of source. It's probably not worse, although I can't help
> muttering "EIBTI". In particular I fin
Hoi,
Fred L. Drake, Jr. acm.org> writes:
>
> On Monday 21 May 2007, A.M. Kuchling wrote:
> > Disadvantages:
> >
> > * reST markup isn't much simpler than LaTeX.
>
> * reST doesn't support nested markup, which is used in the current
> documentation.
For a lightweight markup language that
Hi,
Martin v. Löwis v.loewis.de> writes:
> > Doesn't that mean that there should also be an way to enforce unicode 4.1.0?
>
> You mean, that there should be a ucd_4_1_0 object? No, why do you think
> there should be one? We don't plan to provide a copy of the UCD for each
> UCD version that was
Hi,
I discovered that unicodedata in python2.5 implements unicode 4.1. While
this is ok it's possible enforce unicode 3.2 by using the ucd_3_2_0 object.
But it's not possible to enforce a ucd_4_1_0 standard because that object
does not exist by now.
In the description of #1031288 (http://www.pyth
74 matches
Mail list logo
