Re: [Python-Dev] Why aren't decorators just expressions?

[Éric Araujo]

  Hello,

Le 2017-09-16 à 07:22, Serhiy Storchaka a écrit :
> 16.09.17 12:39, Larry Hastings пише:
>> So why don't decorators allow arbitrary expressions?  [...]
> 
> Actually I remember somebody raised this question a year or two ago,> but 
> don't remember details.

  The discussion I remember was https://bugs.python.org/issue19660

  Guido said: «Nobody has posted a real use case. All the examples are
toys. What are the real use cases that are blocked by this? Readability
counts!»

  Cheers
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg branching + log question

[Éric Araujo]

Le 18/03/2014 04:05, Jeff Allen a écrit :

I found it helpful to practice extensively on something that doesn't
matter. The gap for me is still examples of what I want "done well".
Clearly the Python repos represent complex work, but even accepting it
is all done well, are without much commentary. This is very good:
http://hgbook.red-bean.com/read/ , but there are hints it has not kept up.

This also: http://legacy.python.org/dev/peps/pep-0385/


Does the developer’s guide help?
http://docs.python.org/devguide/patch.html
http://docs.python.org/devguide/faq.html#version-control

Regards
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What code in Python creates .exe launchers for 'entry_points' in 'setup.py'?

[Éric Araujo]

Hello,

Le 01/04/2013 16:51, Grigory Petrov a écrit :
> But what python code is responsible for creation of this bootstrapper
> executables? I have searched python 2.7.3 source code for some time, but
> can't find a place.

Setuptools is not in the standard library, so you would need to search
the setuptools or distribute codebases.

Regards
___
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 443 - Single-dispatch generic functions

[Éric Araujo]

Hi,

Thanks for writing this PEP.  Blessing one implementation for the stdlib
and one official backport will make programmers’ lives a bit easier :)

>   >>> @fun.register(int)
>   ... def _(arg, verbose=False):
>   ... if verbose:
>   ... print("Strength in numbers, eh?", end=" ")
>   ... print(arg)
>   ...

Does this work if the implementation function is called like the first
decorated function? (I don’t know the proper terminology) e.g.

>>> @fun.register(int)
... def fun(arg, verbose=False):
... if verbose:
... print("Strength in numbers, eh?", end=" ")
... print(arg)

The precedent is 2.6+ properties, where prop.setter mutates and returns
the property object, which then overwrites the previous name in the
class dictionary.

> * the current implementation relies on ``__mro__`` alone, making it
>   incompatible with Abstract Base Classes'
>   ``register()``/``unregister()`` functionality. A possible solution has
>   been proposed by PJE on the original issue for exposing
>   ``pkgutil.simplegeneric`` as part of the ``functools`` API
>   [#issue-5135]_.

Making generic functions work with ABCs sounds like a requirement to me,
as ABCs are baked into the language (isinstance).  ABCs and interfaces
(i.e. zope.interface) are really neat and powerful.

> * the dispatch type is currently specified as a decorator argument. The
>   implementation could allow a form using argument annotations. This
>   usage pattern is out of scope for the standard library [#pep-0008]_.
>   However, whether this registration form would be acceptable for
>   general usage, is up to debate.

+1 to passing the type as argument to the decorator and not supporting
annotations.  It’s simple and works.


Question: what happens if two functions (say in two different modules)
are registered for the same type?
___
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 443 - Single-dispatch generic functions

[Éric Araujo]

Le 23/05/2013 16:10, Łukasz Langa a écrit :
>> Does this work if the implementation function is called like the first
>> decorated function?
> No, the ``register()`` attribute returns the undecorated function which
> enables decorator stacking, as well as creating unit tests for each
> variant independently.

Perfect.  My web framework of choice uses decorators that register
things and return the function as is and I love it.  I guess the common
pattern will be to use variants of the generic function name, e.g. func
is implemented by func_int, func_str and co, which also helps debugging.

>> Making generic functions work with ABCs sounds like a requirement to me
> Yes, I will implement that.

Great!

>> Question: what happens if two functions (say in two different modules)
>> are registered for the same type?
> Last one wins. Just like with assigning names in a scope, defining methods
> in a class or overriding them in a subclass.

Works for me.

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] eval and triple quoted strings

[Éric Araujo]

Le 17/06/2013 20:49, Benjamin Peterson a écrit :
> Reading Python coding cookies is outside the purview of TextIOWrapper.
> However, it would be good to have a function in the stdlib to read a
> python source file to Unicode; I've definitely implemented that
> several times.

IIUC you want http://docs.python.org/3/library/tokenize#tokenize.open
(3.2+).

Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of 3.2 in Hg repository?

[Éric Araujo]

Le 21/08/2013 14:22, Tim Peters a écrit :
> BTW, it's not quite a null-merge.  The v3.2.5 release tag doesn't
> currently exist in the 3.3 or default .hgtags files.  So long as 3.2
> has a topological head, people on the 3.3 and default branches won't
> notice (unless they look directly at .hgtags - they can still use
> "v3.2.5" in hg commands successfully), but that's mighty obscure ;-)

IIRC Mercurial looks at the union of .hgtags in all unmerged heads to
produce the list of existing tags. :-)
___
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] Re: Increase of Spammy PRs and PR reviews

[Éric Araujo]

  Hi,

Le 01/02/2022 à 07:25, Martin Dengler a écrit :

The fact people are assuming bad faith and spilling ink about those getting
involved with that extremely-underserved part when contributors are sorely > 
needed is counter-productive.


  I disagree, the original message was a good-faith question about how 
to interpret a pattern.  It is healthy to check with the group to 
discuss if there is a problem and how to deal with it.


  For pull requests, I have recently seen a few contributors who 
clearly want to improve things and just have to be guided with our 
process: when to create a ticket or not, when to add news or not, why we 
don’t use force pushes, why «consistency» is not a sufficient reason to 
make sweeping cosmetic changes that do really fix or improve something, 
etc.  Guidance was well received by these contributors with good intentions.


  I have also noticed drive-by, commentless PR approvals that add zero 
value (often right after a core dev approval), but are counted on the 
person’s github profile and can’t be dismissed (because they have no 
comment, I suppose).
  I think these are minor annoyances; in these two examples the persons 
are teenagers, self-described as tech enthusiasts, so they’re probably 
just following what the github interface encourages without engaging 
with the culture or the real work.
  On one of the PR I wrote a message tagging the person to express that 
reviews from non-core devs can have value, but not if they have zero 
effort behind them (no reply yet).


  Regards
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/O73RIBGQJRCSPBSJH5HMOS6Z6RHURI6R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change

[Éric Araujo]

Le 2020-07-02 à 09 h 52, Paul Moore a écrit :
> What *is* the correct inclusive way to refer to an unidentified person
> in a technical document, without sacrificing clarity by using
> convoluted circumlocutions like "he/her/they" or over-use of the
> passive voice?

One technique is alternating genders for the imagined user or developer.
Otherwise the singular they is the easiest way.

Regards
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5BPV75H6VOCF45EV3A2B2G2QDEIMXWCA/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] versioned .so files for Python 3.2

[Éric Araujo]

Le 24/06/2010 17:50, Barry Warsaw (FLUFL) a écrit :
> Other possible approaches:
>  * Extend the distutils API so that the .so file extension can be passed in,
>instead of being essentially hardcoded to what Python's Makefile contains.

Third-party code rely on Distutils internal quirks, so it’s frozen. Feel
free to open a bug against Distutils2 on the Python tracker if that
would be generally useful.

Regards

___
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] versioned .so files for Python 3.2

[Éric Araujo]

Le 24/06/2010 19:48, Brett Cannon a écrit :
> P.S.: I wish we could drop use of the 'module.so' variant at the same
> time, for consistency sake and to cut out a stat call, but I know that
> is asking too much.

At least, looking for spam/__init__module.so could be avoided. It seems
to me that the package definition does not allow that. The tradeoff
would be code complication for one less stat call. Worth a bug report?

Regards

___
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] versioned .so files for Python 3.2

[Éric Araujo]

Your plan seems good. Adding keyword arguments should not create
compatibility issues, and I suspect the impact on the code of build_ext
may be actually quite small. I’ll try to review your patch even though I
don’t know C or compiler oddities, but Tarek will have the best insight
and the final word.

In case the time machine’s not available, your suggestion about getting
the filename from the Extension instance instead of passing in a string
can most certainly land in distutils2.

Regards

___
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] OS X buildbots: why am I skipping these tests?

[Éric Araujo]

[Barry Warsaw]
> As an aside, I wonder if it would make sense to create an Ubuntu/Debian
> package that essentially just depended on all those -dev packages.  That way
> you could install this python-uber-dev package and get everything you needed
> to build a sumo Python.

I don’t know. Any Debian advanced user wanting to build a package can
just run “aptitude build-dep python2.6”. Aptitude has the nice property
of asking for a confirmation, so it’s even possible to cherry-pick from
the lists of deps (press “e” at the confirmation prompt). E.g., I choose
readline but not tk. So it seems to me that the information and the
command are already here.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Éric Araujo]

The workflow described by Brett looks like a patch-and-email one. It’s
used by the Mercurial team itself, and has the advantage of not
cluttering the history with lots of changes, since you only apply one
patch in the end. However, in the not-so-long run I feel that a simpler
and more mercurialic workflow would be a changesets-and-repos one.

1. Contributor clones the repo.
2. Contributor makes changes, committing as needed.
3. Contributor pushes to some public location and asks for pulling.
4. Core dev reviews and pulls from that repo into the official one.
(optional step) Core dev may make additional edits (e.g. to NEWS and
ACKS) in another changeset.

One advantage of DVCS is that it separates the step of getting ideas
from brain to code (commit) from the step of approving code and putting
it into the official repo (pull). Having both the contributor and the
core dev doing commits seems counter-natural to me.

Advanced users may use MQ or pbranches or bookmarks to refine patches,
but basic usage (commit and pull) still seems worthwhile to me.

> And finally, http://hginit.com/ is one of the best Hg intros I have
> come across for explaining fundamentals.
Agreed, although I’m not sure whether I’d call it a long introduction or
a short tuto :) The “reeducation for Subversion users” page is helpful.
hgtip.com has bite-sized tips for daily use, and
http://hgbook.red-bean.com/ is an excellent read.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

[Éric Araujo]

hg.python.org/cpython is a test setup for people working on the
transition. It is not guaranteed to be usable, it usually lags, and it
will be rewritten before the real switch IIRC.

code.python.org/hg is a mirror kept in sync for use by contributors who
don’t want to use Subversion now.

After the switch, hg.python.org/cpython will be the official repo, and
code.python.org/hg will probably be closed.

HTH

Regards

___
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] Are you ready for Mercurial migration?

[Éric Araujo]

Hello Anatoly

I’m thankful that you give time and energy to the issues raised by the
migration. As a minor contributor, I’m eager for the migration, and I
also find healthy that there is discussion about these things. However,
I think that there is too much discussion right now. I offer some facts
and opinions.

1) The PEP is accepted. Python is migrating to Mercurial and closing the
Subversion repository after lengthy discussion and rounds of feedback.
This is beating a dead horse.

2) Python mailing lists are effective, open to anyone with an email
address, and work with all Web and email clients. Google Wave requires
an account, JavaScript, and learning a new thing. That doesn’t help a
situation where we already lack people and time.

2a) Old tools are not always bad. (Emails works.)

2b) New tools can be helpful, but do not magically solve issues. I can’t
see python-dev moving to Trac or Wave in the coming years, so fighting
for them is not productive.

In a community, it’s important to assume that people have reasons for
their choices, research before jumping to conclusions (e.g. hg uses the
parent changeset ID too to compute the ID of a changeset, so the current
mirror and the new, clean official repo will be incompatible), and say
that everything sucks.

To sum up my opinion: The Mercurial migration will proceed as explained
in the PEP, there are still some areas to discuss, the transition will
be delayed if there’s no committer willing to lead the effort. Debating
agreed issues does not help solving open issues.

Regards

___
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] Are you ready for Mercurial migration?

[Éric Araujo]

> Éric, you letter is discouraging.
That’s the right term. I wanted to discourage you from fruitless endeavors.

> This is not for coredevs, who already "decided" - it for the rest of
> the world.
I don’t think there is a discrepancy between the core devs that want to
keep the power and do what they please, and the community that is never
consulted and unable to express itself. I believe that the core devs are
the first circle of the community and that they strive to make open
technical dicussions and reach decisions for the good of everyone. I
find them open and kind, even if sometimes necessarily stern (e.g. when
answering the same question for the umpteenth time).

> I should clarify it in the first place, but I would like to avoid
> lengthy debates outside of the Wave.
And I would like to keep Python-related discussions on open official
fora that have been working for decades.

>> As a minor contributor, I’m eager for the migration,
> It is not the question about do you like it or not.
That paragraph was just me trying to be positive before expressing my
negative comments.

> It is the question 
> "Are You ready?"
> That means:
> Have you tried Mercurial?
Yes.

> Do you understand how it works?
Yes.

> Do you have a workflow ready and tested to start commiting right away?
Yes. I have a handful of workflows in my belt to address different needs
(one-shot typo fix, feature development, local editions, etc.)

> Do you plan to read ~100 page long hginit.com tutorial after *it happens?
Done. I have read the hg book, information on the wiki, made a lot of
tests, read the PEPs, read the short hginit tutorial, and am willing to
review Python-centered docs.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

[Éric Araujo]

> 2, throwing away local changes is not that easy in Mercurial,
>if you have committed them already. There are extensions to
>uncommit, but they are discouraged and have limitations. So it's
>best to throw away everything and start over fresh, which is
>faster if you have a pristine clone.

If you’re using named branches or bookmarks, there is an easy way to
throw away the whole branch. Say you have a clone with branches default,
fix, fix9008, shlex-unicode (default is clean upstream Python 3.2,
the other three are branches you made for bug fixes or features). Now
you want to discard shlex-unicode.

 $ cd ..
 $ mv cpython cpython.old
 $ hg clone cpython.old cpython -r default -r fix -r fix9008
 $ rm -r cpython.old

The new repo will only contain the branches you ask for. Giving all
names on the command line may be cumbersome if you’re on a lot of
branches at one, but it’s okay for a small number. A small bit of shell
scripting can automate that easily (get all branches, remove the one
given as argument to the shell function, mv, hg clone, rm).

Of course, a branch you wan to abandon can stay in your repo for a while
if you don’t want to clean up now.

HTH. Regards


___
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] Are you ready for Mercurial migration?

[Éric Araujo]

>> That tutorial is not ~100 pages. It's actually a good tutorial.
> That's why I posted it here, but it still >80 pages in my browser.

Perhaps you meant 80 screens, or a different tutorial. hginit is a short
tutorial useful for Subversion users who don’t have the time to read the
hgbook.

Regards


___
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] blocking 2.7

[Éric Araujo]

> But Python tests lack coverage stats, so it is hard to say anything.
FYI: http://coverage.livinglogic.de/

Regards


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

[Éric Araujo]

The other risk with history-editing extensions is that they use the
merge and rebase machinery to do their work, so they require a clean
working directory. Otherwise you may loose uncommitted changes.

Not requiring any Mercurial extension to contribute to Python would be a
nice policy to lower the entry bar.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

[Éric Araujo]

>> Not requiring any Mercurial extension to contribute to Python would be a
>> nice policy to lower the entry bar.
> 
> That is already defeated by the need for the eol extension (which is now
> built-in in hg 1.6).  Activating mq is something every developer should
> manage...

Okay, make that “not requiring any third-party Mercurial extension” :)

Some extensions are too useful to be left out, and since they’re shipped
with Mercurial the cost of using them is null (patchbomb, eol,
bookmarks, graphlog, progress, relink, crecord, rebase).

MQ is another beast, it’s a new way of using Mercurial for middle or
advanced users.

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] Mercurial migration readiness

[Éric Araujo]

 Not requiring any Mercurial extension to contribute to Python would be a
 nice policy to lower the entry bar.
>>>
>>> That is already defeated by the need for the eol extension (which is now
>>> built-in in hg 1.6).  Activating mq is something every developer should
>>> manage...
>>
>> Okay, make that “not requiring any third-party Mercurial extension” :)
> 
> mq is anything but third-party.

Sorry, I didn’t want to imply that. What I meant was: Since eol is
already a requirement, and since extensions provide tremendously useful
things, it’s okay to require or recommend some of them.

MQ is in another category IMO not because it’s not shipped-with, since
it is, but because it makes you think differently that regular Mercurial
usage. (Not saying better or worse, just differently, thus a bit more
difficult for would-be contributors.)


> mq contains the strip command.

Which fits into regular Mercurial usage without requiring any MQ
knowledge, agreed.


By the way, is eol a requirement for people using Windows tools with
limitations only, or for every person that will clone Python?


Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

[Éric Araujo]

> I'm not sure if I misunderstand Martin's intent, but in principle, if you
> want to merge one changes (not changesets!) branch into another, all you
> need to do would be "hg merge ".   Subsequently committing
> the merge (after fixing conflicts) creates a new changeset "on" the current
> branch.

Indeed, merges are branch-wise operations, not changeset-wise. You need
tricks to copy one changeset from a named branch into another one.

Copying changesets between a stable branch and a devel branch is easy if
the devel history is a strict superset of the stable history. Every
changesets landing into stable can then just be pulled into devel. This
means no different named branches for stable and devel. Not sure I’m
clear enough, I hope Mercurial experts can chime in.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

[Éric Araujo]

[Martin Geisler]
> You basically need to replay the changes -- the transplant extension can
> do this for you. This is more or less a wrapper around 'hg export'
> (gives you a diff) and 'hg import' (applies the diff).

Core developers seem to be okay with svnmerge, so perhaps a
familiar-looking command like transplant (with “merges” that are
actually replays, and explicit blocking for bookkeeping) will feel right
to them.

> It sounds like you are describing how Mercurial itself was developed
> before we began using named branches.

Spot on, sir!

> [snip] You'll notice the small labels saying 'stable' on the changesets
> from that branch -- that is the whole difference.

Thanks for the explanation. The new workflow seems quite good.

Regards

___
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] Signs of neglect?

[Éric Araujo]

Hello pydev

I’d like to volunteer to maintain a tool but I’m not sure where I can
help. I’m already proposing changes to Brett for
Tools/scripts/patchcheck.py, and I have commented on Tools/i18n bugs,
but these ones are already maintained by their authors (e.g. Barry is
assigned pygettext bugs) and I’m by no means a gettext expert.

If I adopt a tool, it will still require some core dev time to review
and commit, but I’ll do the bug triage, discussion and coding.

I suggest that each adoption starts with a reindent.py run and a PEP 8
compliance check. Let demos and tools become a showcase to be proud of!

I have opened a bug to discuss adding a simple sanity test that would
just make sure tools and demos can run without syntax errors:
http://bugs.python.org/issue9153

There was an open bug about demos, http://bugs.python.org/issue7962,
I’ve widened it into a meta-bug for demos and tools. (I hope it is
okay.) Please comment, adopt or condemn demos and tools in that report.

Hope this helps.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

[Éric Araujo]

>> Because it's not a transition. It's a mirror. It was put in place
>> before the hg migration plan was accepted, IIRC.
> Where is this migration plan then if it is not in PEP?

The “hg migration plan” is PEP 385. It means moving from svn.python.org
to hg.python.org.

It is not possible to make code.python.org/hg a mirror of the future
official hg repo (a quick search on the hgbook or the Mercurial wiki
will tell you how changeset hashes work). The code.p.o/hg repo was a
simple read-only mirror provided as a service to the community. Now that
the official repo will be a new, clean Mercurial repo, the current
mirror will become redundant and will probably be closed. People using
that mirror to follow cpython development and/or propose patches will
just redo a clone and rebase their patches.

>> The two sets of repositories use different conversion tools and rules.
>> They have nothing in common (different changeset IDs, different
>> metadata, different branch/clone layout).
> That would be nice to hear about in more detail. As I understand there
> is no place where it is described.

The layout of the future official repo is in PEP 385. The layout of the
old mirror can be understood by looking at the Web interface (one repo
per svn maintenance branch, etc.)

> The transition can be complete in a few minutes. The question is how
> good it will be. As there are no plan, no roadmap, no status

The transition is not just a command to be run, it includes discussion
and writing tools before that, and feedback and support after that. What
we call transition is the whole process. People have worked and are
still working on the PEP, on the repo, on the policy and on the
documentation, and it is unfair not to acknowledge that work and say
there is no plan.

Regards

___
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] query: docstring formatting in python distutils code

[Éric Araujo]

> I promised to write a PEP about that some time in the future.  (Probably after
> 3.2 final.)

Nice.

It seems that projects putting Sphinxy reST in their doc are using
automatic doc generation. This is however not always the best way to
make good doc, as demonstrated by Python’s hand-written,
very-high-quality documentation.

> Agreed.  However, reST doesn't need to be less readable if the specific
> inline markup is not used.  For example, using `identifier` to refer to a
> function or *var* to refer to a variable (which is already done at quite a
> few places) is very readable IMO.  Using ``code`` also isn't bad, considering
> that double quotes are not much different and potentially ambiguous.
> 
> Overall, I think that we can make stdlib docstrings valid reST -- even if it's
> reST without much markup -- but valid, so that people pulling in stdlib doc-
> strings into Sphinx docs won't get ugly warnings.
> 
> What I would *not* like to see is heavy markup and Sphinx specifics -- that
> would only make sense if we included the docstrings in the docs, and I don't
> see that coming.

Clear answer, thanks! We have backported some modules in distutils2, and
some docstrings already contain Sphinxy reST (e.g. :param: and :pep:),
it’s good to know now that we shouldn’t put hours into that to see it
reverted later.

Regards

___
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

[Éric Araujo]

> I was actually going to suggest something along those lines post
> transition, since Hg will have an email address for everyone - leave
> push notifications coming from the bot (so existing filters based on
> the bot address keep working), but include the push author in the
> reply-to field.

IIRC, you can’t know who pushed without kludgy hackery. Also, the one to
push is not necessarily the author of the commit(s). If that was just a
braino and you meant setting the committer as reply-to, it seems a good
idea.

Note that nothing in Mercurial forces you to have a parsable
“Name ” user name, it’s just a good practice. Dirkjan’s mapping
uses a dummy to...@python.org address for unknown IDs, which probably
means the other tools he’s writing depend on an email address. That
would need to be in the dev policy.

Regards

___
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] notifications form Hg to python-checkins

[Éric Araujo]

[Nick]
>[me]
>> IIRC, you can’t know who pushed without kludgy hackery.
> 
> [...] Note that the current distutils2 emails to python-checkins
> already say "Tarek Ziade pushed..."

I looked at mail.py in the hooks repository and learned that hooks get
an HGPUSHER variable in their environment. Nice!

Regards

___
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] Markup of command-line options in Python's .rst documentation

[Éric Araujo]

> The "--help" option appears as a hyperlink leading to
> http://docs.python.org/dev/py3k/using/cmdline.html#cmdoption--help, which is
> hardly relevant or useful. [...]
> 
> -h/:option:`--help`
>print a short usage message and exit

I think this is a doc bug in Doc/documenting/markup.rst
:cmdoption: and :option: are not clearly distinguished; the latter
creates references to using/cmdline, the former is what you’re looking
for for documenting trace.py.

Regards

___
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] Markup of command-line options in Python's .rst documentation

[Éric Araujo]

Le 19/07/2010 04:57, Eli Bendersky a écrit :
> On Sat, Jul 17, 2010 at 16:44, Éric Araujo  wrote:
>> I think this is a doc bug in Doc/documenting/markup.rst
>> :cmdoption: and :option: are not clearly distinguished; the latter
>> creates references to using/cmdline, the former is what you’re looking
>> for for documenting trace.py.

I had actually misunderstood the documentation here. Georg corrected me
in http://bugs.python.org/issue9288 and made the right fix (thanks!)

Kind regards

___
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] Markup of command-line options in Python's .rst documentation

[Éric Araujo]

Le 19/07/2010 04:57, Eli Bendersky a écrit :
> On Sat, Jul 17, 2010 at 16:44, Éric Araujo  wrote:
>> I think this is a doc bug in Doc/documenting/markup.rst
>> :cmdoption: and :option: are not clearly distinguished; the latter
>> creates references to using/cmdline, the former is what you’re looking
>> for for documenting trace.py.

I had actually misunderstood the documentation here. Georg corrected me
in http://bugs.python.org/issue9288 and made the right fix (thanks!)

Kind regards

___
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] What to do with languishing patches?

[Éric Araujo]

Le 18/07/2010 23:17, Alexander Belopolsky a écrit :
> On Sun, Jul 18, 2010 at 5:02 PM, Mark Lawrence  
> wrote:
>> Maybe going off on a tangent, but I find it frustrating because you (plural)
>> can't find a given module on the issue tracker.  Say I'm looking for issues
>> relating to smtplib, all I can do is look in the title of the issue.  Have I
>> missed something, or is there a need to have subsections so that if Lib is
>> selected, you can then find the appropriate module?
> 
> I don't think you missed anything and I would also find this feature
> useful.  For example, I recently took interest in datetime and pickle
> modules, but other than full text search, there was no way to find all
> issues related to either of these two modules.  The "Components" list
> is somewhat arbitrary with narrow components such as ctypes and broad
> components such a Lib.

When I suggested such a modules list on
, R. David Murray
replied “This has been suggested and rejected a number of times on
python-dev” but I have been unable to find those discussions.

Regards

___
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] :program: markup in .rst documentation

[Éric Araujo]

> Sorry to add the third way to the mix, but shouldn't the recommended
> way to run a module as a script be python -m modname?  As in
> 
> $ python -m test.regrtest test_spam

This is true but orthogonal to our problem, which is that
:program:`python -m thing` is wrong if I understood the doc rightly and
should be replaced by ``python -m thing``.

Regards

___
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] Set the namespace free!

[Éric Araujo]

>  Using "setattr" to set attributes, where the attribute string
> comes from an external source, can create a security hole.  Remember
> that you can override functions on an object, for that object only,
> by setting an attribute.  This offers the opportunity for an attack
> similar to SQL injection.  Think about what this can do to a parser
> that has and calls a method "display" for each element:
> 
>   
> 
> You are pwned.

Nope. You’d have to give setattr a function object, not a string.

Regards

___
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] Set the namespace free!

[Éric Araujo]

>  Using "setattr" to set attributes, where the attribute string
> comes from an external source, can create a security hole.  Remember
> that you can override functions on an object, for that object only,
> by setting an attribute.  This offers the opportunity for an attack
> similar to SQL injection.  Think about what this can do to a parser
> that has and calls a method "display" for each element:
> 
>   
> 
> You are pwned.

Nope. You’d have to give setattr a function object, not a string.

Regards

___
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] proto-pep: plugin proposal (for unittest)

[Éric Araujo]

Le 30/07/2010 17:04, Michael Foord a écrit :
> There is no type checking or interface requirements in my plugin 
> proposal for unittest. It is essentially an event based system.

Event-based sounds good. unittest2 does have an interface IMO:
configuration loading, plugin registration/activation, signal names.

As you said, the common ground may be little more than an API to
discover or register plugins, activate and configure them, and the
design decision of using events and callbacks, but even this small
subset is very much worth a PEP.

Regards

___
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] proto-pep: plugin proposal (for unittest)

[Éric Araujo]

> It has an API, but the plugins are not interface based (so interface 
> requirements don't need to be part of the plugin system).

Oh, I see. With duck-typing and ABCs, I don’t make a difference between
protocols and interfaces in my head :) Also, the I in API does mean
interface, but not imply bondage-and-discipline interface systems.

> PEP 376 is *very* promising for this part - well at least if the PLUGINS 
> stuff becomes part of PEP 376, it doesn't seem to be mentioned at all at 
> the moment.

The dist-info directory introduced by PEP 376 will certainly be reused.
Not sure if Tarek will want to edit PEP 376 (already accepted) to add
plugins in metadata (provides-dist is in metadata, so having plugins
here can make sense), or start a new PEP about a new concept in a new file.

Regards

___
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] proto-pep: plugin proposal (for unittest)

[Éric Araujo]

>> Note that the PEP 376 implementation is mainly done in pkgutil. A
>> custom version lives in distutils2 but
>> when ready, will be pushed independently in pkgutil
> 
> Ok. It would be helpful for unittest2 (the backport) if it was *still* 
> available in distutils2 even after the merge into pkgutil (for use by 
> earlier versions of Python). I guess you will do this anyway for the 
> distutils2 backport itself anyway... (?)

Yes. Even if the goal is to have distutils2 in the stdlib for 3.2 or
3.3, there will still be a standalone release on PyPI for Python
2.4-3.1. You’ll just have to write such compat code:

  try:
  from pkgutil import shiny_new_function
  except ImportError:
  from distutils2._backport.pkgutil import shiny_new_function

Regards

___
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] No response to posts

[Éric Araujo]

Good call.

Alternative idea: Have a new status “unread” to make searching easier
for bug people. Or a predefined custom search for nosy_count == 1.

Regards

___
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] No response to posts

[Éric Araujo]

> Perhaps just another number to track in the weekly bug summary?

*puts bug person hat on* I made the same suggestion to Ezio, so +1

I’ve just created a public query named “Reports without replies”, you
should be able to add it to your queries list, or a tracker admin could
decide to add it to the queries that are always visible in the sidebar.

Regards

___
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] proto-pep: plugin proposal (for unittest)

[Éric Araujo]

> Speaking of which... Your documentation says it's named ~/unittest.cfg,
> could you make this a file in the user base (that is, the prefix where
> 'setup.py install --user' will install files)?

Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
other in the user home directory (or %APPDATA% on win32 and
what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
is not the right directory for configuration files, as pointed in
http://bugs.python.org/issue7175

It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
$XDG_CONFIG_HOME/python directory and put config files there.

Regards

___
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 376 proposed changes for basic plugins support

[Éric Araujo]

> The PLUGINS file can be kept only for the state value, which is not read-only.

It will be for OS packages.

Regards

___
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 376 proposed changes for basic plugins support

[Éric Araujo]

Le 02/08/2010 14:31, exar...@twistedmatrix.com a écrit :
> On 12:21 pm, m...@egenix.com wrote:
>> Do we really need to make Python packaging even more complicated by
>> adding support for application-specific plugin mechanisms ?
>>
>> Packages can already work as application plugins by simply defining
>> a plugins namespace package and then placing the plugin packages
>> into that namespace. [...]
>
> This is also roughly how Twisted's plugin system works.  One drawback, 
> though, is that it means potentially executing a large amount of Python 
> in order to load plugins.  This can build up to a significant 
> performance issue as more and more plugins are installed.

If namespace packages make it into Python, they would indeed solve a
part of the problem in a nice, generic way. Regarding the performance
issue, I wonder if functions in pkgutil or importlib could allow one to
iterate over the plugins (i.e. submodules and subpackages of the
namespace package) without actually loading then. We would get only
their names though, not their description or any other information
useful to decide to activate them or not. Maybe importing is the way to
go, with a doc recommendation that people make their plugins subpackages
with an __init__ module containing only a docstring.

Regards

___
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] No response to posts

[Éric Araujo]

> Well, I just feel like we keep changing things to little result,
> creating an organic mess of fields and statuses. Adding more queries
> is fine, but let's not bow to the temptation to add more fields.

AFAICT, Ezio certainly wants to solve the status/stage/resolution
unclear overlap, and in general making the UI better (this means
removing things).

Regards

___
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 376 proposed changes for basic plugins support

[Éric Araujo]

> What you might want to do is add new type fields to PEP 345,
> making it easier to identify and list packages that work as
> plugins for applications, e.g.
> 
> Type: Plugin for MyCoolApp
> 
> The MyCoolApp could then use the Type-field to identify all
> installed plugins, get their installation directories, etc.
> and work on from there.

Classifiers seem a good way to do that. They’re already defined in
accepted PEPs, extensible on demand, used by Web frameworks
components/applications/middlewares/things and other projects, and
queriable in PyPI.

We could use “Environment :: Plugins” and “Framework :: Something” or
define a new classifier (not all applications are frameworks, and
“plugins” seems a very strange value for “environment”).

It would be the first time that a classifier triggers specific
processing from distutils though, so we may prefer to define a new
Provides-Plugin field for consistency and explicitness.

Regards

___
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] barry_as_FLUFL

[Éric Araujo]

Hello


> hmm... BARRY_AS_BDFL and barry_as_FLUFL

Oh, bad consistency. Should have been BARRY_AS_FLUFL and barry_as_flufl.

 from __future__ import barry_as_FLUFL
> nothing noticable happened.

I made some tests about that and found that the behavior didn’t match
the PEP; I have to redo experiments and eventually report bugs.

> I googled the latter, and found that it's an April
> Fools (of 2009!) checkin that was never reverted.

Why should it be reverted? It causes no harm.


Regards


P.S. from __future__ import braces

___
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 376 proposed changes for basic plugins support

[Éric Araujo]

Hello

Le 03/08/2010 13:09, Michael Foord a écrit :
> On 03/08/2010 09:28, M.-A. Lemburg wrote:
>> P.J. Eby wrote:
>>> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
> [idea about sqlite3 db for caching]
 [distros won’t like it, the filesystem is the db]
>>> [the db is a cache, it does not replace the files]
>> [advantages of sqlite3 db]
> Sounds good as an "optional extra" (i.e. it should be safe to completely 
> delete the cache file and still have everything work) to me. If the API 
> for using the feature is worked out well first this could be done as a 
> behind the scenes optimisation...

FYI, the current implementation in the distutils2-augmented pkgutil uses
a cache (a function call memo) for functions that e.g. iterate over
dist-info directories (and optionally egg-info directories too) or get a
Distribution object representing an installed project. Tools that modify
the state of the installation can call a function to clear this cache.

A sqlite db would certainly speed things up; it could replace the
existing caching in distutils2 or be left to other tools.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed tweaks to functools.wraps

[Éric Araujo]

> The second (#9396) came up in the context of the new cache decorators
> added to functools, and allowing applications to choose their own
> caching strategies. I suggested exposing the original (uncached)
> function, and Raymond suggested that the easiest way to enable that
> would be for functools.update_wrapper to add a new attribute that
> provides a reference to the original function.

I moved this feature request to its own bug after brief IRC discussion
with RDM: http://bugs.python.org/issue9567

The idea was to separate concerns and eventually get feedback from
people reading new-bugs-announce, but your email actually does that :)

I say “add attribute to partial objects” in the bug title since I don’t
know if it’s feasible in wraps only; while update_wrapper is simple
Python code, wraps merely delegates to _functools.partial, so please
change the title (and maybe add easy keyword) if appropriate.

Regards

___
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] Fixing #7175: a standard location for Python config files

[Éric Araujo]

Hello list

Tarek opened a distutils bugs in http://bugs.python.org/issue7175 that
evolved into a discussion about the proper location to use for config files.

Distutils uses [.]pydistutils.cfg and .pypirc, and now unittest2 has a
config file too.

It would be nice to define one standard location for config files used
by stdlib modules, and maybe also by third-party programs related
closely to Python development (testing tools, static code checkers and
the like), in a way that doesn’t clutter the user home directory with a
dozen dotfiles while still being easily found.

(The Unix notions of dotfiles and home directory have to be adapted to
use non-dotfiles in some standard place on various Windows. The Mac
experts disagree on the right directory to use.)

Tarek, Antoine, RDM, MAL were +1 on using ~/.python (whether to use
.pythonx.y or .python/x.y is a subissue to discuss after general agreement).

What do you think about this?

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

[Éric Araujo]

> I'd like to see a more complete proposal, including:
Fair enough.

tl;dr: Locating config files is hard.

I have looked at http://github.com/ActiveState/appdirs (MIT) for
OS-specific bits of knowledge. (Note that the directories it uses for
free OSes are not compliant with the freedesktop.org Base Directory
specification, which already did the reflexion and code to separate
config, user data and cache.)

> - what to do with Windows,
appdirs uses pywin32 or ctypes or _winreg to find the correct value for
the user settings directory. There is a new complication in recent
Windows called roaming profiles, which are copied from a server to
multiple clients and need synchronization calls.

> Mac OS X
There is debate between Ned Deily, Ronald Oussoren and Glyph Lefkowitz
as to whether Mac OS is just a Unix or a special beast. appdirs chooses
the Mac-specific directory. There are also probably variations between
system installations, framework things and unix-style installations.

> - backward compatibility considered
>   (seems straightforward, but seemings are often wrong)
Are you talking about finding config from older locations, or automatic
renaming of ~/.idlerc to ~/.python/idlerc? The former seems easy; not
sure how to do the latter. Gajim, a PyGTK Jabber client, moved from a
custom layout to BaseDir-compliant directories a few months ago; I think
it looks for the old directories on every startup to see if they need to
be moved. I’m not sure if this affects startup time noticeably, since
it’s after all a graphical network Python app, but it may be a concern
with programs that are run a lot like the unittest2 script (or not,
considering startup time of the interpreter).

> - cross-platform API to locate these files
I was thinking about adding a function to site with this tentative
signature:

def getuserconfig(appname=''):
"""Return the configuration file name for `appname`.

If `appname` is the empty string, return the directory used for
Python configuration files, else returns the file name used for the
configuration file of `appname` (a PyPI project name).

Strings starting with a number ('3.2') are reserved by Python.
"""

I’m not sure the x.y subdirectory is necessary. distutils config files
are compatible since forever and will still be compatible with
distutils2; config files in unittest2 are very recent, they could have a
policy of compatiblity too; I can investigate IDLE config format.

A boolean could control whether to return filenames using the old
conventions. On Windows, this would need application name and
author/vendor name (settings are grouped by author). On Mac, the
application would have to say whether it uses a unix-style dotfile or a
Mac-style directory. Also, capitalization differs across OSes. Can of
worms here.

> Seems like a good idea to have a "registry" of files known to be placed there
The project name registration on PyPI may be enough to avoid duplicates.


Next steps:

1) Find out if winreg is reliable enough, since we don’t want to depend
on ctypes or pywin32 IIRC.

2) Have the Mac people come to an agreement for each type of install.

3) Prototype the new function. It’s probably a good idea to contact the
author of appdirs and work with him on a Python-specific subset of his
module instead of rewriting the same code.

4) Think about the best way to handle b/w compat. Timings could help
deciding for or against automatic renaming.


Thanks for the feedback.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

[Éric Araujo]

> PEP 370 already specifies a directory for Python config files:
> 
>> user data directory
>>
>> Usually the parent directory of the user site directory.
>> It's meant for Python version specific data like config
>> files, docs, images and translations.

Thanks for pointing that. However, I have to disagree with the PEP here:
config files are not data files. Considering the FHS or the XDG Base
Directory specifications, there is a precedent in distinguishing user
config (edited by the user through a text editor or settings graphical
window), program data (state) and cache (files for speedups that can
safely be deleted).

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

[Éric Araujo]

>> If the files are shared among all users then /usr/local/
>> seems more reasonable.

Oh, right, I forgot to think about system-wide config files. They have
to be supported by another function in site.

A lot of programs have similar-looking code to get a list of filenames
and then process it with configparser or something else:
find_config_files in Distutils, get_standard_config_files in Docutils,
rcpath in Mercurial. There are different namings to support (rc, .cfg,
.conf, etc.) and also config directories (for Mercurial), but it does
not seem impossible to define a standard function that would benefit
Python itself and other programs.

> Choosing an arbitrary location we think is good on every system is fine
> and non risky I think, as long as Python let the various distribution
> change those paths though configuration.

Don’t you have a bootstrapping problem? How do you know where to look at
the sysconfig file that tells where to look at config files?

> In fact, that's one of the future goal of the sysconfig module I had in mind.

Seems great.

> So let's:
> 
> - define all the default locations for each system
> - define a sysconfig.cfg file that contains all installation paths,
> for each target system
> - change sysconfig.py so it uses it, instead of the global dicts it
> currently has

I wonder if this is so complex that a wiki page or something else would
be better suited than email to iron out the proposal. Or maybe it’s time
for that sysconfig.cfg PEP you planned to do.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

[Éric Araujo]

Le 12/08/2010 12:18, Steve Holden a écrit :
> Didn't we have this discussion when per-user libraries came up?
> Shouldn't we be using a subdirectory of that location?

As pointed out by Antoine, Georg, Michael and I, the PEP 370 directory
for user site-packages is not the right place to put config files.

> PS: Then we can start putting the libraries themselves in the database.
> That works really well.

I don’t know you well enough to tell if this is the final hint that you
were sarcastic.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

[Éric Araujo]

> Ultimately, I don't feel very strongly about this subject. I'm more
> concerned that the chosen location (file or registry or whatever) be
> documented -- and documented from a Windows perspective as well, so
> you don't have to guess what "HOME" means in this context.

Rest assured that I don’t want to impose Unix concepts on Windows. My
examples have used dotfiles since it’s what I know, but I did search and
ask for the right thing to do on other platforms.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

[Éric Araujo]

> A good alternative would be to make the config file overridable.  That way
> you can have sysconfig.cfg next to sysconfig.py or in a known config
> directory relative to the python stdlib install but also let the
> distributions and individual sites override the defaults by making changes
> to /etc/python3/sysconfig.cfg for instance.

Putting configuration files next to source code does not agree with the
FHS. Your message gave me an idea though: Some function could be called
in sitecustomize (symlinked from /etc on Debian e.g.) to set the path to
sysconfig.cfg.

___
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] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst

[Éric Araujo]

Thanks for the replies.

The dev FAQ is clear about regular use, it tells about the
svnmerge-commit-message too, and people in #python-dev have told me that
the merge order is py3k > 3.1, py3k > 2.7. My problem here is that I
committed r84190 in 3.1 manually, but it should have been an svnmerge of
r84187. So my question is: Do I have to svnmerge block -r84187 in 3.1?

> And I use "svnmerge block -r revision" for branches where the commit
> should not be applied, don't forget to do this.

Oh, this has to be done for every commit? I have for example fixed typos
in 3.x that don’t apply to 2.7, so I have to block them?

Regards

___
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] r84190 - python/branches/release31-maint/Doc/library/stdtypes.rst

[Éric Araujo]

Thanks Eric for the reply and Nick for mentioning --record-only, this
was what I needed.

Tarek: I find the bug tracker simpler than svnmerge to keep track of
merges to be done. Of course, when there is no report, as for the typo
fixes I made, this doesn’t help. Oh well.

I’m going to do some Mercurial merges to feel better. In case the PSU
wants me to svnmerge block/record the few changes I committed without
using svnmerge afterward, tell them I won’t be far.

Regards, and thanks for helpi

___
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] Released: Python 2.6.6

[Éric Araujo]

> The question really is whether there is any chance that they will get
> released, in some form. There won't be further binary releases (at least
> not from python.org), so there definitely won't be a CHM release.

I think that the most important release is docs.python.org/2.6,
regardless of python.org/OS-specific downloadable doc packages.

If people do like haypo and use the most recent docs instead of the
version-specific ones, there’s indeed no need to bother with porting doc
fixes and improvements. If people use docs.py.org/2.6 as a reference for
some years while 2.7 is not on their systems, it may be worthwhile to
keep updating those docs.

Regards

___
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] Update Shell profile for ZSH on Mac OS

[Éric Araujo]

Hi Sylvain

> Sorry for errors in the e-mail and the patch, but i'm french student

Being polite or cautious is a good thing in Internet communication, but
you don’t have to apologize about that. Everyone tries to express
themselves as clearly as possible, but nobody is judged because of
language. When someone makes a patch with a typo, the right reaction is
to say “thank you” and to fix the typo.

More information: http://ostatic.com/blog/more-bad-english-please

> and it is my first patch.

We’ve all been there, don’t worry. We won’t bite, even if people may
appear abrupt in such technical discussion (well, there are also real
flamefests for some sensitive topics :).

Thank you for your contribution.

Regards

___
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] Released: Python 2.6.6

[Éric Araujo]

Thanks everyone for the feedback. I think my question has got good
answers (usage patterns, versionchanged/versionadded, lack of releases,
opinion of the doc editor), so it seems good for our users and for
developers to let the 2.6 docs in peace.

Regards, and a toast to 2.6.6!
___
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] Buffer protocol for io.BytesIO?

[Éric Araujo]

> It just occurred to me that it could be interpreted as a breach of the
> moratorium. On the other hand, according to PEP 3003:
> 
> “The case for adding a method to a built-in object can be made.”
> 
> This case seems even lighter than adding a new method.

I’ve been satisfied to see other proposals breaking the moratorium being
refused. Respecting rules set by ourselves for the benefit of other VMs
sends a good signal.

In this case, the PEP leaves an opening (quoted line above), the change
should be very easy to implement in other VMs, and it’s an elegant way
of adding a useful feature. +1 from me.

Regards

___
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 LRU cache API in Py3.2

[Éric Araujo]

> What about adding an intermediate namespace called "cache", so that the new 
> operations are available like this:
> 
>  print get_phone_number.cache.hits
>  get_phone_number.cache.clear()
> 
> ?
> 
> It's just a little more overhead, but I think it reads quite a bit better.

Or we could use pseudo-namespacing: get_phone_number.cache_hits,
get_phone_number.clear_cache()

Regards

___
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] Volunteer help with porting

[Éric Araujo]

> Sure I will look into this. Could you please point me towards the
> repository(I'd love it if I could use mercurial for the development process
> rather than svn)?.

Core developers still use Subversion (we’re in the process of
switching), but you can clone the mirror at
http://code.python.org/hg/branches/py3k/ and use named branches for your
work. You can look for bugs needing patches on bugs.python.org or open
reports and then post patches.

The email package is a high-priority task, but it’s not trivial.
R. David Murray and Shashwat Anand will maybe comment about the status
of the port.

Other interesting bugs:
http://bugs.python.org/issue7962
http://bugs.python.org/issue8077

Maybe you can post a call on python-list and form a small group of py3k
porters.

Happy hacking

___
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] terminology for "free variables" in Python

[Éric Araujo]

> Yeah, I changed my mind and have now documented it properly. The 3.2
> versionadded tag on show_code is currently a little questionable
> though. Guido actually checked in the original (undocumented) version
> of show_code before 3.0 was released. The only thing new about it in
> 3.2 is it being mentioned in the documentation.

versionadded marks the addition of a feature (see
docs.python.org/documenting), so it should be removed here.

Regards

___
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] r84619 - python/branches/py3k/Misc/developers.txt

[Éric Araujo]

Author: georg.brandl
Date: Wed Sep  8 12:43:45 2010
New Revision: 84619

Log:
Add Lukasz.

I guess you had to asciify Łukasz’ name because developers.txt is in
Latin-1, which cannot encode the first character.  I think the file
should be recoded to UTF-8 so that we have no artificial restrictions on
people’s names.  I’ll wait some days and if nobody disagrees I’ll recode
the file and fix the name.

Regards

___
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] r84619 - python/branches/py3k/Misc/developers.txt

[Éric Araujo]

> I would agree, but also suggest a latin transcription for 
> non-latin-alphabet names.

I think that people whose alphabet is for example Cyrillic already use a
Latin transliteration in those files, so it’s good.  Are you also
including names using extended Latin alphabets (like Łukasz) in your
suggestion?

Regards

___
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] r84619 - python/branches/py3k/Misc/developers.txt

[Éric Araujo]

>> I think that people whose alphabet is for example Cyrillic already use a
>> Latin transliteration in those files, so it’s good.
> At present, such people have no choice ;-).

Right :)  So the new policy of real name thanks to UTF-8 + ASCII
transliteration is a superset of the existing conditions, which should
be fine with everyone (i.e. names can finally be written with whatever
characters they require, and people in the old world can read it with
non-UTF 8-capable tools).

>> Are you also including names using extended Latin alphabets (like
>> Łukasz) in your suggestion?
> No.

Then it’s fine.


Thanks for the feedback.  Regards

___
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] r84743 - in python/branches/py3k: Doc/license.rst Misc/NEWS Modules/expat/COPYING

[Éric Araujo]

+zlib
+
+
+The :mod:`zlib` extension is built using an included copy of the zlib
+sources unless the zlib version found on the system is too old to be
+used for the build::

Unless or if?  Building with an included copy *if* the system one is too
old makes sense to me, not the contrary.  Am I not seeing something?

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.x as the official release

[Éric Araujo]

Le 15/09/2010 21:45, Tarek Ziadé a écrit :
> Could we remove in any case the wsgiref.egg-info file ? Since we've
> been working on a new format for that (PEP 376), that should be
> starting to get used in the coming years, it'll be a bit of a
> non-sense to have that metadata file in the sdtlib shipped with 3,2

+1 on removing wsgiref.egg-info in the same version that ships with
distutils2, or with 3.2 (in case they’re not the same version).

> I am not really sure what was the intent to have it there in the first
> place though.

Unless I remember wrong, the intent was not to break code that used
pkg_resources.require('wsgiref').

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.x as the official release

[Éric Araujo]

> * add a decorator to wsgiref that supports using native strings as 
> output instead of bytes, for ease-of-porting (combine mod_wsgi's 
> ease-of-porting w/"flat"'s simple verifiability)

Ah, thanks, I’ve been reading web-sig and was totally at a loss to
understand what a “native string” was.  Now I get it’s a character
string / string / str object / former unicode object.

FWIW, I’m glad to see concern for web-sig in python-dev, and messages
from Web people in python-dev.  Some threads going “they broke strings,
we can’t use the stdlib” were a bit alarming to me.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.x as the official release

[Éric Araujo]

Le 15/09/2010 21:45, Tarek Ziadé a écrit :
> Could we remove in any case the wsgiref.egg-info file ? Since we've
> been working on a new format for that (PEP 376), that should be
> starting to get used in the coming years, it'll be a bit of a
> non-sense to have that metadata file in the sdtlib shipped with 3,2

On a related subject: Would it make sense not to run install_egg_info
from install anymore?  We probably can’t remove the command because of
backward compat, but we could stop running it (thus creating egg-info
files) by default.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.x as the official release

[Éric Araujo]

> If you're talking about distutils2 on Python 3, then of course 
> anything goes: backward compatibility isn't an issue.  For 2.x, not 
> writing the files would indeed produce backward compatibility problems.

I was talking about distutils in 3.2 (or in the release where
wsgiref.egg-info goes away).  install_egg_info.py has already been
turned into install_distinfo.py in distutils2, following PEP 376.

Thank you for your reply, I withdraw my suggestion.

Regards

___
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] r84858 - in python/branches: py3k/Doc/library/logging.rst release27-maint/Doc/library/logging.rst

[Éric Araujo]

Hello

+   NOTE: If you are thinking of defining your own levels, please see
the section
+   on :ref:`custom-levels`.

I think those instances of upper-case-as-markup should either be real
reST note/warning/etc. directives or plain English (that is, integrating
“NOTE:” into the text flow, for example “Note that...”/“Pay attention
to...”).

Regards

___
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] r84871 + committing distutils fixes

[Éric Araujo]

>+@unittest.skipIf(sys.platform.startswith('win'),
>+"This test is only appropriate for POSIX-like
systems.")

Is win32 the only non-POSIX supported platform now that OS 9 support is
gone?  I find those values in the docs for sys.platform: win32, cygwin,
darwin, os2, os2emx.  Is OS/2 a POSIX system?  Isn’t it more robust not
to ask this question and just use unittest.skipUnless(os.name ==
'posix', msg)?

On a related note, I’m very grateful that other developers take time to
reply to bugs and commit simple fixes that don’t require knowledge of
distutils dark corners.  Recent changes have tended to turn buildbots
red though, so I’d like to respectfully ask/remind you to make sure to
run tests before committing in each branch (3.2, 3.1, 2.7), if possible
on POSIX and Windows.  (Those are Tarek’s rules, not mine; I hope don’t
sound bossy or ungrateful for your help.)  I apologize in advance if you
did run the test and the buildbots just revealed an unforeseen
platform-specific quirk; I’m not accusing anyone of anything—I have my
share of embarrassing commits, so be sure I’m not judging here, I just
want to improve the process. :)

It would also be very helpful to always add the Distutils2 component so
that synchronizing the fixes is not overlooked.  (Maybe I should add a
tracker admin to automate that.)

mport-unittest-ly yours

___
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] r84906 - python/branches/py3k/Doc/library/ssl.rst

[Éric Araujo]

> Log:
> Remove references to read() and write() methods, which are useless
> synonyms of recv() and send()

Unless I’m mistaken, ssl.SSLSocket.write is still useful for use with
print, pprint and maybe other functions, so I think the method should be
listed somewhere.

Regards

___
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] Goodbye

[Éric Araujo]

Le 23/09/2010 19:22, Terry Reedy a écrit :
> As of just now, if you were to wonder "What (security) bugs are open for 
> 2.5" and search on open 2.5 issues, you would get a list of 44 issues. 
> It is only 44 instead of hundreds because of the work I and Mark have 
> done in the last 4 months. It it 44 instead of perhaps 5 because Tarek 
> and Eric insist on marking all disutils2 issues for all versions even 
> though though these issues have nothing to do with maintenance releases. 
> It is a real nuisance when trying to do tracker cleanup.

Let’s fix this.  Two days ago, I said this in
http://bugs.python.org/issue2200#msg117003 :

 distutils2 has to work with 2.4-2.7 and (soon) 3.1-3.2, so Tarek told
 me to set all available versions for those bugs (2.5-py3k), even if I
 think “3rd party” is more appropriate and useful (since a distutils2
 bug would not for example block a CPython 3.2 release).

I’ve been following these rules since before GSoC, when I had less
confidence and no will to conflict with Tarek on such a small thing
.  Now I argue that the versions field is not really useful for
d2, since it lacks 2.4 which we support and chiefly because it does not
actually help our workflow: We don’t have separate branches for
backporting fixes, we apply patches and run tests for all supported
versions before committing on a single branch.  There is no use case of
setting a version to remind that a port needs to be done.  For bug
purposes, I actually see distutils2 as a value for the versions field of
distutils bugs.

In short, setting versions other than “3rd party” for distutils2 bugs
does not help distutils2 and raises unhelpful results for people
querying the status of CPython releases.  +1 on changing that.

respect-my-non-ASCII-diversity-write-my-acute-accent-thanks’ly yours,

Éric

___
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] Goodbye

[Éric Araujo]

How about revamping the type/versions fields?

Issue type
() Feature request (blocked by moratorium: () yes () no)
() Bug (found in: [] 2.7 [] 3.1 [] py3k)
() Security bug (found in: [] 2.5 [] 2.6 [] 2.7 [] 3.1 [] py3k)

I’m getting tired of explaining the meaning of the versions field again
and again, let’s put this information directly under the eyes of the bug
reporter.

Regards
___
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 wiki

[Éric Araujo]

Hello

Le 25/09/2010 10:20, anatoly techtonik a écrit :
> On Fri, Sep 24, 2010 at 1:27 AM, Nick Coghlan  wrote:
>> That's a good point actually... why *isn't* there a pydotorg-wiki-sig?
>> (Aside from the obvious point of nobody ever asking for one).
> 
> Because Yet Another Mailing List doesn't solve the problem.
> If you need one - go Google Groups like packaging folks did.
> Python ML are:
> 1. require dedicated admin to update, who is not a member of the group
> 2. don't have search
> 3. don't have optional thread subscription
> That's already enough to seek better platform for collaboration.
This is debatable.  Google Groups require a Google account, are not
controlled by python-dev, require JavaScript to view the archives, don’t
send MIME digests.  The public archives for python.org MLs are indexed
by Web search engines and are therefore searchable.

Re: thread subscription, there is a setting about topics in the mailman
admin but I don’t understand it.  I suppose a good email client can do
something equivalent.

> Community can perfectly manage the stuff without dedicated admins if
> there is a gameplay in it.
I don’t agree with the split between admins and community.  Admins are
just trusted people from the community (which includes python-dev).

> My advice - subscribe people editing page by default (a checkbox near
> submit button).
+1 wholeheartedly.

>> With an admin team behind it, you can also make more use of ACLs to
>> flag certain parts of the wiki as "official" by making them only
>> editable by certain people
I don’t know if this would be noticed enough to change the image of the
wiki.  I had started reviewing and updating all pages pertaining to
distutils and distutils2 some months ago, and I viewed the wiki as a
collaborative area to hash things out, before they can become official
code or docs.

Regards

___
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] distutils and distutils2 bugs (Was: Re: Goodbye)

[Éric Araujo]

Le 23/09/2010 22:51, Éric Araujo a écrit :
> Le 23/09/2010 19:22, Terry Reedy a écrit :
>> As of just now, if you were to wonder "What (security) bugs are open for 
>> 2.5" and search on open 2.5 issues, you would get a list of 44 issues. 
>> [...] It it 44 instead of perhaps 5 because Tarek
>> and Eric insist on marking all disutils2 issues for all versions even 
>> though though these issues have nothing to do with maintenance releases. 
>> It is a real nuisance when trying to do tracker cleanup.
> 
> Let’s fix this.  [...]
> 
> In short, setting versions other than “3rd party” for distutils2 bugs
> does not help distutils2 and raises unhelpful results for people
> querying the status of CPython releases.  +1 on changing that.

There has been no further feedback after Georg (thanks Georg), so I went
ahead and set “3rd party” for distutils2 bugs instead of 2.5-3.2, for
all the aforementioned reasons.  Bugs applying to distutils and
distutils2 have versions 2.7, 3.1, 3.2, 3rd party so that the
forward-port is not forgotten.

If you commit a change to distutils, sysconfig or pkgutil, it’s fine to
assign the forward-port to me or, if you can use Mercurial, to publish a
changeset somewhere and request a pull/import.

(Those versions changes sent a lot of email, but this had to be done.
Sorry for the inconvenience.)

Thanks again to Terry and Mark for their triage work.  Hope this helps!

Kind regards
___
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] question/comment about documentation of relative imports

[Éric Araujo]

> If they were actively discouraged, perhaps performing a relative
> import would raise a warning,
This would be done if this import style was deprecated.  It’s different
from it being discouraged.

> or maybe distutils would raise a warning at install time,
Distutils does not inspect source files.

> Up until now, I was not aware that use of PEP 328 relative imports
> might be discouraged. I'm still unclear as to why they might be
> discouraged.
I think relative imports are a nice thing.  I think they’ve been added
because there are people who want them, and the previous implicit
relative imports caused so much pain.  Neither the FAQ you quote nor PEP
8 really explain what’s bad about explicit relative imports.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils2 scripts

[Éric Araujo]

Le 08/10/2010 17:31, Jon Ribbens a écrit :
> I'd just like to say "pypackage" again.

In the Python world, a package is a directory with an __init__.py file.
 Distutils and distutils2 try to avoid confusion and call the other
things “distributions”.

Of course, everyone outside of the Python world thinks a distribution is
an operating system that has a free kernel and a package manager.  Maybe
we should trade “distributions” for “bundles”.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils2 scripts

[Éric Araujo]

Le 12/10/2010 01:11, Giampaolo Rodolà a écrit :
> Wouldn't be kinda weird that one can open the command prompt and run
> "pysetup" but not "python" on Windows?
> I recall an old issue on the bug tracker in which the latter proposal
> was widely discussed and finally rejected for reasons I can't remember
> (and it seems I can't even find the bug right now).
> I think it's likely that those same reasons are valid for "pysetup" in
> the same manner.

Arguments for rejection by MvL in http://bugs.python.org/issue3561 :

“Adding something to PATH is nearly unacceptable clutter even during
installation, and completely unacceptable (to me) after uninstallation.
If you install Python several times, will the path get longer and longer?”

“To me, any change to PATH is a problem... (I really think that software
installation should never ever touch it - this aspect of the operating
system completely belongs to the user resp. the system administrator)”

“If such a solution was designed, there would still be many questions,
such as:
- what is the actual problem being solved? Is it real? Could there
  be other solutions to that problem (such as installing things into
  system32, or somewhere else that is on the PATH already)?
- if the path is modified, should the Python directory be added to
  the beginning or the end?
- IMO, this feature needs to be customizable, and IMO, it must be
  turned off by default. So how should such customization be offered?”

Regarding pysetup, would it be acceptable to require programmers on
Windows to edit their PATH or copy the script to a directory on PATH?

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing zipfile.BadZipfile to zipfile.BadZipFile

[Éric Araujo]

Hello

[Sorry if this comes twice, connection errors here]

(A bit of context: The original message comes from bug #2775, “Implement
PEP 3108”, a meta-bug tracking stdlib reorganization for py3k.)

> I am very glad you're reorganizing the Standard Library. Thumbs up! I
> hope everything will comply to PEP 8 after you're done.

You may have missed the timeline: Most of the PEP 3108 changes have been
done before the first 3.x release went out.  Now that we have 3.1 out as
a stable and supported, we cannot reorganize and break compatibility
anymore.

(A note about PEP 8 compliance: Module names have been mostly fixed, but
not all function/method names, for example in logging and unittest.  If
I recall correctly, readability did not seem to make all the rewrites
worth it.)

> Since you're reorganizing, I have my own contribution. I have attached
> a patch. The issue7351  was not
> accepted at the time, so I hope you'll accept this fix now.

I’ve just re-read the answers there and they are still valid.

Ezio and me: “Your patch need to include an alias (BadZipfile =
BadZipFile) to preserve compatibility with old pickles, as explains
msg95477.”

Antoine: “I don't think changing it for the sake of aesthetics is a good
deal given that many existing programs will have to be converted to the
new spelling.”

Regards

___
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] About resolution “accepted ” on the tracker

[Éric Araujo]

Hi everyone

[Sorry if this comes twice, connection errors here]

Raymond Hettinger noticed on the tracker that there are different
interpretations of the “accepted” resolution:

> Traditionally it denotes an approved patch, not a agreement that the
> bug is valid.

Daniel Stutzbach and I are (were) two users of the second meaning.  It’s
more useful to follow Raymond’s meaning, so that a simple query can find
all accepted patches that are awaiting commit.

I don’t remember if I took up this use from R. David Murray or someone
else, so I thought I’d redirect the message to python-dev so that all
triagers can see it.  Forward to python-list as you see fit, I’m not
subscribed there.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing zipfile.BadZipfile to zipfile.BadZipFile

[Éric Araujo]

Hello

(A bit of context: The original message comes from bug #2775, “Implement
PEP 3108”, a meta-bug tracking stdlib reorganization for py3k.)

> I am very glad you're reorganizing the Standard Library. Thumbs up! I
> hope everything will comply to PEP 8 after you're done.

You may have missed the timeline: Most of the PEP 3108 changes have been
done before the first 3.x release went out.  Now that we have 3.1 out as
a stable and supported, we cannot reorganize and break compatibility
anymore.

(A note about PEP 8 compliance: Module names have been mostly fixed, but
not all function/method names, for example in logging and unittest.  If
I recall correctly, readability did not seem to make all the rewrites
worth it.)

> Since you're reorganizing, I have my own contribution. I have attached
> a patch. The issue7351  was not
> accepted at the time, so I hope you'll accept this fix now.

I’ve just re-read the answers there and they are still valid.

Ezio and me: “Your patch need to include an alias (BadZipfile =
BadZipFile) to preserve compatibility with old pickles, as explains
msg95477.”

Antoine: “I don't think changing it for the sake of aesthetics is a good
deal given that many existing programs will have to be converted to the
new spelling.”

Regards

___
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] About resolution “accepted ” on the tracker

[Éric Araujo]

Hi everyone

Raymond Hettinger noticed on the tracker that there are different
interpretations of the “accepted” resolution:

> Traditionally it denotes an approved patch, not a agreement that the
> bug is valid.

Daniel Stutzbach and I are (were) two users of the second meaning.  It’s
more useful to follow Raymond’s meaning, so that a simple query can find
all accepted patches that are awaiting commit.

I don’t remember if I took up this use from R. David Murray or someone
else, so I thought I’d redirect the message to python-dev so that all
triagers can see it.  Forward to python-list as you see fit, I’m not
subscribed there.

Regards

___
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] My work on Python3 and non-ascii paths is done

[Éric Araujo]

Congratulations Victor!  This is not a small feat.  The PSU should send
you cookies to thank you, but they won’t since they don’t exist and

___
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] r85733 - in python/branches/py3k: Doc/library/logging.rst Lib/logging/__init__.py

[Éric Araujo]

+``Filters` can be used by ``Handlers`` and ``Loggers`` for more
  ↑ missing ` here.

Regards

___
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] Misc/python-mode.el (was Re: r85838 - python/branches/py3k/.gitignore)

[Éric Araujo]

I remember a discussion about Vim files some time ago.  I use Vim with
the files from Misc/Vim, which are up-to-date and more useful than the
files shipped with Vim.  I don’t use plugins or external files, so I’m
-1 on removing Misc/Vim.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing zipfile.BadZipfile to zipfile.BadZipFile

[Éric Araujo]

> From: *Boštjan Mejak* 
> Since Python 3.2 accepts feature requests, take this fix as a feature
> request. Please forget about preserving the compatibility with old pickles.

You can reopen #7351 as a feature request for 3.2.  A serious proposal
has to take compatibility into account, note.  It is simply not possible
to break everyone’s pickles for a very minor inconsistency in one name.
 There is a wide Python world out there.

I’d like to suggest again that the time you want to give to Python
(thanks!) would be better employed on something else than BadZipfile.
For example, if you don’t think you can contribute code now, you could
suggest improvements for unclear sections in the documentation.  Recent
reports sent by beginners can be found on the archives of the
d...@python.org mailing list.

Regards

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing zipfile.BadZipfile to zipfile.BadZipFile

[Éric Araujo]

Le 28/10/2010 22:52, anatoly techtonik a écrit :
> Can anybody summarize the outcome?
> Is it that renaming BadZipfile to BadZipFile with backward compatible
> alias and deprecation note breaks something?

See #7351 or r85874.

Regards

___
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] r86170 - in python/branches/py3k: Doc/library/stdtypes.rst Lib/test/test_unicode.py Misc/NEWS Objects/stringlib/string_format.h Objects/unicodeobject.c

[Éric Araujo]

> Author: eric.smith
> Date: Thu Nov  4 18:06:58 2010
> New Revision: 86170
> 
> Log:
> Issue #6081: Add str.format_map. str.format_map(mapping) is similar to 
> str.format(**mapping), except mapping does not get converted to a dict.

> Modified: python/branches/py3k/Doc/library/stdtypes.rst
> ==
> --- python/branches/py3k/Doc/library/stdtypes.rst (original)
> +++ python/branches/py3k/Doc/library/stdtypes.rst Thu Nov  4 18:06:58 2010
> @@ -1038,6 +1038,14 @@
> that can be specified in format strings.
>  
>  
> +.. method:: str.format_map(mapping)
> +
> +   Similar to ``str.forrmat(**mapping)``, except that ``mapping`` is

Yarrr me hearrties, it be forrrmat!

___
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] r86170 - in python/branches/py3k: Doc/library/stdtypes.rst Lib/test/test_unicode.py Misc/NEWS Objects/stringlib/string_format.h Objects/unicodeobject.c

[Éric Araujo]

According to #python-dev, there’s no need to go through
python-checkins/-dev for typos, so I fixed this one in r86247.

Piratical regards

___
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] r86264 - python/branches/release27-maint/Lib/distutils/sysconfig.py

[Éric Araujo]

> I'm skeptical that this change should be carried out, then.
Yes, I asked myself the same question.  I had done the svnmerge from
py3k, and when I saw that only one change was left, I wondered whether I
should commit or revert.

> It's easy to argue that this can't possibly hurt (but I can certainly
> come up with code that will break under that change); however, I fail
> to see what good it does.
This was a private function used on an unsupported platform, this should
do no harm.  We’ve been bitten by “should do no harm” before though, so
I am ready to revert this change (and learn from this :)

Regards

___
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] r86276 - python/branches/py3k/Lib/distutils/cygwinccompiler.py

[Éric Araujo]

>> New Revision: 86276
>> Log:
>> Fix #10252 again (hopefully definitely).  Patch by Brian Curtin.
> 
> It seems this and previous fixes should be backported to 2.7.

Certainly.  I was waiting on buildbot feedback before doing it.

Regards

___
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] r86276 - python/branches/py3k/Lib/distutils/cygwinccompiler.py

[Éric Araujo]

>> It seems this and previous fixes should be backported to 2.7.
> 
> Perhaps there should be a 'backport 2.7' keyword to check on issues that 
> might be but have not been.

The “Your issues” list is very helpful and works well for me.  This bug
is still open and assigned to me (and opened in my web browser,
incidentally), so I don’t fear I’ll forget it.  This new keyword would
IMO be redundant with existing fields (status:open + version:2.7).

(The once-existing 26backport was entirely different if I recall
correctly, it was used to tag 3.x features to be added to 2.x.)

Regards

___
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] r86300 - in python/branches/py3k: Misc/NEWS PC/winsound.c

[Éric Araujo]

> Author: hirokazu.yamamoto
> New Revision: 86300
> Log:
> Issue #6317: Now winsound.PlaySound only accepts unicode with MvL's approval.
> 
> 
> Modified: python/branches/py3k/Misc/NEWS
> ==
> --- python/branches/py3k/Misc/NEWS(original)
> +++ python/branches/py3k/Misc/NEWSSun Nov  7 15:29:26 2010
> @@ -251,6 +251,8 @@
>  Extension Modules
>  -
>  
> +- Issue #6317: Now winsound.PlaySound only accepts unicode.
> +
>  - Issue #6317: Now winsound.PlaySound can accept non ascii filename.

Shouldn’t that be only one entry?

Regards

___
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] r86264 - python/branches/release27-maint/Lib/distutils/sysconfig.py

[Éric Araujo]

[Martin]
>>> It's rather a matter of agreeing when moving forward: IMO, mere style
>>> changes, code cleanup etc shouldn't be applied to the bug fix branches,
>>> as their only purpose is to provide bug fixes for existing users.
>>
>> [Terry]
>> The omission of the deletion from the 5/5 revision was a bug in that
>> revision. If the removal of OS9 support was documented (announced),
>> which I presume it was, then one could consider any visible trace
>> remaining to be a bug.

FTR, it was documented in PEP 11 as removed in 2.4 (but not in 2.4’s
whatsnew).

> Well, the question is: can anything break due to the code removal.
> In principle, stuff *could* break even by a function that is supposedly
> unused, and had supposedly been removed. The problem is that a
> supposedly-unused function actually might be used somewhere, in some
> context unrelated to its intended usage.

It’s known that people do modify distutils.sysconfig._config_vars, a
private dictionary; I can imagine some really contrived example of code
using _init_mac, the function I removed, to set sysconfig values for Mac
OS 9 in 2.7 code.  1% chance, I guess.

>> Perhaps the policy on code cleanup should be a bit more liberal for 2.7
>> *because* it will be maintained for several years and *because* there is
>> no newer 2.x branch to apply changes to.
> 
> You mean, it's ok to break stuff with no gain in 2.7 bug fix releases?

I don’t think Terry was suggesting breakages, just other kinds of
cleanup.  In this particular case, I think now that I should have
followed distutils policy (which is less liberal that the rest of the
stdlib).  If there are no arguments against it this week, I will revert
the commit.

Regards

___
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