However, as the proposal doesn't
force one to use u prefixes, I'm not really objecting, especially if it speeds
transition to 3.x.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
though it has been addressed somewhat in the PEP,
it would be nice to see the suggested on-installation hook fleshed out a little
more.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
ions from hit-and-run contributors without changes, ISTM that could
compromise the quality of the codebase somewhat.
Also, is not the overall impact on the codebase of hit-and-run contributors
small compared to more the impact from involved contributors?
Regar
/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
es 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
-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 o
son. (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
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) h
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
s 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 -
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,
#x27;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
rd.
> 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.py
jango, 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 - ju
he least amount of code change, and the least ugly code.
"Least ugly" is subjective; I find u'xxx' less pretty than 'xxx' for text.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://
approach: I for one will try to use the unicode_literals approach wherever I
can.
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
Nick Coghlan gmail.com> writes:
>
> On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip yahoo.co.uk>
wrote:
> > If the 2.x code depends on having u'xxx' literals, then 3.2 testing will
> > potentially involve running a fixer on all files in the project every time
hould. If there is a known application of non-ASCII native strings,
> I surely would like to know what that is.
I can't think of a specific instance off-hand, but I seem to recall having
problems with some of the cookie APIs insisting on native strings (rather than
text, which is validated against
ICT, the incidence of native strings in an application is not that great (of
course there can be pathological cases), so the number of calls to n() or
whatever it's called is unlikely to have any significant impact. Even when I was
using u() calls with the 2.5 port - which are of c
7;s a one-time operation using a lib2to3 fixer, and even for a big
project like Django, we're not talking about a lot of time spent on this (at
least, in my experience). Having a good test suite helps catch those byte-string
cases more easily, of course.
Regards,
Vinay Sajip
__
ependency in that case.
> (see https://bitbucket.org/pitrou/t3k/)
Yes, 2to3 is very useful when doing an initial porting exercise. I've used it
just once in each port I've done. It also works well for a single codebase
approach, only I just follow its advice rather than letting it do the
low, and which in part
prompted the PEP in the first place.
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
> After the initial conversion of the code base, the fixes are mostly
> trivial, so people don't need to write two patches (most of the patches
> we get for CPython are either against 2.7 or 3.2, and sometimes they
> even apply clearly to both).
Fixes may be trivial, but new
the files in the Django codebase. And
if it's going to know only which files have changed and run only on those, how
does it propose to do that, independently of my editing tools?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@pyth
cept that this only works well with Python 2.6.
Let's hope not. We can mitigate that by spelling out in the docs that there's
no one right way, how to choose which approach is best for a given project, and
so on.
Regards,
Vinay Sajip
__
cal go-to guide - they don't seem to do so currently.
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
e prospects for 3.2 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
quent (i.e. the
unicode_literals and n() case).
Of course, if the PEP is targeting Python 2.5 and earlier where unicode_literals
is not available, then it should say so. I would say that the overall impression
given by the PEP is that "the unicode_literals approach is not worth both
cognitive burden on developers.
I'm not whinging about the PEP in this post - I've said elsewhere that I wasn't
opposed to it. I'm just trying to respond to your apparent bewilderment at some
of the reaction to the PEP.
I have confidence that with your continued i
text format, but only as native
strings). It would be a shame to leave these APIs as they are indefinitely, and
perhaps using a marker like n('xxx') for native strings would help to remind us
that these areas need addressing at some point.
Regards,
Vinay Sajip
__
nfidence
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.
Your comments would be appreciated.
Regards,
Vinay Sajip
___
Pytho
ever, I don't believe that the "use a single codebase,
use six or six-like techniques, use unicode_literals, use the 2to3 fixer to
remove unicode prefixes, and use native string markers where you need to"
message has received anything like the same level of airpla
one -
just putting my point of view forward about porting from 2.x -> 3.x, as others
have done - that's not OT, is it?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
y are there to suit the requirements of legacy APIs which pre-date
Python 3 and the latest versions of Python 2. In terms of practicality, it is
IMO quite practical (assuming 2.5 / earlier support can be dropped) to move to a
2.6+/3.x-friendly codebase, e.g. by using Armin's python-modernize.
R
year. I initially wrote a fixer to transform
u'xxx' to u('xxx') (as I was assuming 2.5 support was needed), and then, when it
appeared likely that Django would drop 2.5 support after 1.4, I wrote a fixer to
go from u('xxx') to 'xxx&
urce and reason for this error.
It's because you're using the free "Express" edition of Visual Studio, and not
the full, paid-for Visual Studio.
However, I believe you can ignore the error, and the solution should still be
built. (I'm not absolutely sure, as I use the
PyPI. I have done basic testing with it, and it should also
work as expected in virtual environments.
The implementation uses lib2to3, though that could be changed if needed.
You can also, of course, use it in Python 3.3 right now (before the PEP gets
implemented).
Please take a look at it, try it out,
hook() in __enter__() and unregister_hook() in __exit__()?
Of course, things like this can be added without too much trouble.
Thanks for the feedback.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
t 2to3 in the PEP). People should be free to use what's best for
their use cases and development work processes.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
ts effect on the transformed code, what are the
differences between this hook and running 2to3 with just the fix_unicode fixer?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
roblems emerge in practice, rather than trying to shoot it down
before it's even got going.
Regards,
Vinay Sajip
"It is not enough merely to win; others must lose." - Gore Vidal
___
Python-Dev mailing list
Python-Dev@python.org
ht
too much
work, should that prove necessary or desirable.
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
s not overwritten.
Before raising an issue I thought I'd check here, in case it's something to do
with my configuration. Can anyone else confirm my findings?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://
been it - thanks. I uninstalled, removed the key from the
SharedDLLs (it was still there with a refcount of 1, as per your analysis),
reinstalled and uninstalled - all is well.
I did raise an issue but I'll go and close it now. Thanks for the help.
n of the PEP no longer mentions those
figures.
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
atistical variation.
As I mentioned in my other post, I happened to have the Django test suite
figures to hand, and to my mind they suited the purpose of showing that wrapper
calls, in the overall mix, don't seem to have a noticeable impact (whereas they
do, in a microben
y entries, but that isn't
currently in place.
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
any changes required as a result of resolving open issues.
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
ed as objectionable.
Regards,
Vinay Sajip
[1] http://bugs.python.org/issue14452
[2] http://bugs.python.org/issue7077
[3] http://bugs.python.org/issue8795
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
meant to be overridden and so not private).
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
omments would be appreciated.
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
#x27;
The trailing space later causes a mismatch with the end tag, and leads to the
errors. Django's use of the tagfind pattern is in a subclass of HTMLParser, in
an overridden parse_startag method.
Do we need to indicate more strongly that data like tagfind are private? Or has
the change
hem. Can anyone please let me know if they object? Otherwise I'll
go ahead and add them to .hgeol in the next hour or so.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
ndows utilities) has trouble.
>
> Not sure if that makes a difference or not.
It's only really an issue for new / inexperienced users, I agree. Since these
files are installed only on Windows systems, there's no reason for them not to
have the native
table's path, and try with that.
I would prefer to use option 2 and change getpath.c / getpathp.c accordingly.
Does anyone here see problems with that approach?
Regards,
Vinay Sajip
[1] http://stackoverflow.com/a/933996
___
Python-Dev m
or now, and see where the other failures lead me
to.
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
tool will need to only update environments which were
set up with the particular version of Python which was updated. ISTM pyvenv.cfg
will need to have a version=X.Y.Z line in it, which is added during venv
creation. That information will be used by the tool to only update specific
environments.
you to have an isolated set of library
dependencies for a project.
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/
ironment variable,
__PYTHONV_LAUNCHER__, which points to itself, before it execs the real Python.
On OS X, Python code checks for this, rather than sys.executable, to determine
the location of the pyvenv.cfg file. This seems to work for me (Ned Deily is
looking into it more closely, I believe).
Rega
nt.
Agreed it's not essential, but it also provides some useful information about
the version (for a user, rather than the update script) without actually having
to invoke the interpreter to check.
Regards,
Vinay Sajip
___
Python-Dev mail
e.g. for issue
http://bugs.python.org/issue1521950
Is it something I'm doing wrong, or is there a problem with the issue
tracker/Rietveld integration?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
week since I'm on vacation for one week
> from June 2nd.
I believe it is ready to integrate now. I aim to do it tomorrow (26 May) a.m.
UTC, so that it can make the next alpha.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Pyt
week since I'm on vacation for one week
> from June 2nd.
It's now implemented in the default branch :-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
Python 3.3.
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
ight now? It will need
integrating with the existing VS2010 solution file, and at the moment I cannot
do that integration because I haven't yet got a full VS2010 build environment,
just a VS2008 one.
Regards,
Vinay Sajip
___
Python-Dev mailin
ackaging. If people
generally feel strongly about this, I can delete the .exe and re-introduce it
later if/when appropriate. It might have had a few rough edges, but I wouldn't
have characterised the patch as "half-finished" - that seems a littl
n 01381723bc50 - the
.exe is gone.
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
separately.
There's nothing in there related to #12394 - just a pysetup3.exe file, which I
had originally overlooked and have now removed.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
he stock
launcher; any script installed by packaging (or setuptools/Distribute) in a venv
should have the correct shebang line, and the PEP 397 launcher should do the
right thing.
I'm sorry for all the confusion I've caused here :-(
Regards,
Vinay Sajip
__
Antoine Pitrou pitrou.net> writes:
>
> Deciding to remove packaging from 3.3 is another instance of the same
> mistake, IMO.
>
What's the rationale for leaving it in, when it's known to be
incomplete/unfinished?
Regards,
Vinay Sajip
_
tuptools doesn't seem to
be something to bet the future on. As an infrastructure concern, this area of
functionality definitely needs to be supported in the stdlib, even if it's a
painful process getting there. The barriers seem more social than technical, but
hopefully the divide-and-co
format for review/edit,
though.
+1 to the overall approach suggested, it makes a lot of sense. Simple is better
than complex, and all that :-)
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
Nick Coghlan gmail.com> writes:
> ini-style is often good enough, and failing that there's json. Or, you
> just depend on PyYAML :)
Except when PyYAML is packaged and distributed using dist.yaml :-)
Regards,
Vinay Sajip
___
Python-De
unication between hooks
and code reuse between hooks. I don't see any drawback to using only one file ?
I was assuming that the dist.yaml file would just have callable references here;
I suppose having (sizable) Python fragments in dist.yaml might become unwieldy.
enough on Posix platforms, perhaps, but what about Windows? One can't
expect a C compiler to be installed everywhere. Perhaps security against
backdoors could also be provided through other mechanisms, such as signing of
binary installers.
Regards,
Vinay Sajip
___
have allowed backdoors, etc. I don't see that it mandates use of
SSL, or even signing, by anyone. At least some people will require that an
installer be invokable with an option that causes it to bail if any part of
what's being installed can't be verifie
mething like that in an earlier message).
> I do have concerns about making signed code mandatory. (Not least over
> whether it'd let me install my own unsigned code!)
Any workable mechanism would need to be optional (the user doing the installing
would be the decider as to whethe
v.loewis.de> writes:
>
> See above. Also notice that such signing is already implemented, as part
> of PEP 381.
>
BTW, I notice that the certificate for https://pypi.python.org/ expired a week
ago ...
Regards,
Vinay Sajip
___
Pyt
racks. The basic low-level
building blocks like versioning, metadata and markers should be fine, but I'm
not convinced that the command-class paradigm is appropriate in this case. The
whole intricate "initialize_options"/"finalize_options"/"set_undefined
ment work to date, but it
seems the net needs to be spread even wider to ensure that all constituencies
are represented (for example, features needed only on Windows, such as binary
distributions and executable scripts, have lagged a little bit behind).
Regards,
Vinay Sajip
stutils' way of
fulfilling those needs is too fragile - else, why do you need things like Bento?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
and fall into oblivion.
Quite possibly, but that'll be the chicken-and-egg thing I mentioned. Some
projects can be worked on in comparative isolation; other things, like
packaging, need inputs from a wider range of people to gain the necessary
credibility.
Regards,
Vinay Sajip
eme position in order to suggest that
there might be problems with its basic design.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mail
work on the venv code was done
using a clone from this mirror, and I pulled and merged from it lots of times
without any issues.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
n dependency graph logic
glob.py - globbing functionality
The code was taken at around the time packaging was removed, and may not have
more recent changes.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
Tarek Ziadé ziade.org> writes:
> > Regards,
> oh, cool !
>
> maybe we could copy it at hg.python.org ?
>
Sure, but I don't know if I can do it. IIUC it needs someone with an account on
the server to create new repositori
iles in there - a Makefile, configure script and some
.bat files.
I tried cloning it but I'm not allowed to create a repo at the top level - it
says
Please use a secondary level path such as "sandbox/distlib"
Seems a shame not to make it a top-le
Antoine Pitrou pitrou.net> writes:
> On the other hand, if you are not using hg.python.org features such as
> commits e-mails or buildbots, it's also fine living on bitbucket until
> the project matures a bit.
>
I'm fine with tha
de is already in the distutils2.install_distinfo.install_distinfo.run()
method. I'll pull it out into such a method.
Anyone else, do chip in if you think this is insufficient or sub-optimal.
Perhaps these discussions (on the detail) should continue on distutils-sig. I'll
post there when I&#x
larly as there may be security
implications (the issue is titled "Improve the security model for logging
listener").
Barring objections, I plan to commit it in a week or so.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@
r callback to be specified
- is sufficient to allay the concerns that led to the issue being raised in the
first place. In which case, I can close the issue without committing this patch.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python
nd
what shouldn't be.
ISTM there is a space for a limited evaluator that's less limiting than
literal_eval(). I do realise that this type of sandboxing is not easy to
achieve,
and I'm not aiming to advance the state of the art here - I just want to close
the iss
f I clean the default repo and re-run make, it fails at the
ASDLGEN step, because the $HOME/bin/python3.4 script fails, due to not being
able to invoke $HOME/projects/python/default/python.
Is this a bug in configure, or is my configuration regarded as too perverse to
s
bin/python2.7
Aha! Thanks for pointing that out.
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
uilt Python 3.4. Ned's post showed me why.
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
Eli Bendersky gmail.com> writes:
> Use pss [http://pypi.python.org/pypi/pss]
How does it compare with grin? [http://pypi.python.org/pypi/grin]
On the face of it, they both do the same job.
Regards,
Vinay Sajip
___
Python-Dev mailing list
support for the multi-valued "Provides", but I'm
not confident that will work as expected given pathological cases like the
example I suggested, without getting "complicated" in the Zen of Python sense.
I'm not convinced that the maintenance burden of a complicated solu
lues in Provides-Dist? If they are
e.g. a bundled SQLAlchemy, why would that be preferable to an entry in
Requires-Dist?
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
missing from the package
> index based purely on the distribution names.
In which case, it seems sensible to put these constraints into the PEP,
so that both PEP implementers and users of those implementations have these
guidelines clarified.
Regards,
Vinay Sajip
___
n X.Y? I take it we're entirely comfortable with installing
setuptools X.Y in that case? How would you ensure the right setuptools is
always loaded, since presumably both are on sys.path?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-D
301 - 400 of 437 matches
Mail list logo
