[Python-Dev] Re: Retiring this mailing list ?

[Baptiste Carvello]

Le 13/11/2023 à 11:17, Marc-Andre Lemburg a écrit :
> Hello everyone,

Hello,

> for quite a while now, core discussions have moved to Discourse and
> people are obviously enjoying things there: […]

Enjoying is a big word. I for one am more or less coping with it, using
rss for now (read-only and with holes in discussions).

> The Discourse mailing list mode works reasonably well, so is a suitable
> replacement for this mailing list.

It is not, as every user needs to waste time configuring category
filters, which most won't do anyway. Those problems were discussed here
some months ago, to no avail. Discourse is designed for logged-in
reading with the web interface, everything else is second class citizen.

> Posts to this list are now mostly spam, mailer error reports and the
> occasional release postings:

This is sadly the fact.

> Question: Should we retire and archive this mailing list ?
> (I'm asking as one of the maintainers of the ML)

Indeed.

Cheers,
Baptiste
___
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/R6HLH7I7LSQJ2TBOHD7E4BJPL4YWSOTY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Baptiste Carvello]

Le 10/12/2022 à 22:51, Cameron Simpson a écrit :
> 
> In short: copying the Discourse stuff to mailman could be done by
> subscribing the mailman list to the Discourse forum.  Letting
> _nonDiscourse_ users reply or post to Discourse is not trivial.

IMHO it would already be a nice achievement if these two things could be
done:

- subscribe the mailman list to the *relevant parts* of the Discourse
forum; that would be more or less the Core Development and PEP
categories (you must know better than me: is there anything else your
filters let in?)

- let *Discourse users* reply to those list messages from their mail
client with their known-to-Discourse address (is the From address enough
for Discourse to recognize the user?)

Cheers,
Baptiste
___
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/7BKLNTBUYLXY2WONH6AD2L3XMU6AYTGK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Baptiste Carvello]

Hi,

Le 10/12/2022 à 13:21, Stephen J. Turnbull a écrit :
> 
> as far as
> I can see the Mailman side is handled as well as it can be now that
> Discourse provides threading information, and you just subscribe
> Mailman to Discourse.
There is a small catch though: unless I'm mistaken, Discourse won't let
you subscribe to just a set of categories, so any filtering has to
happen on the Mailman side.

If we wanted an equivalent of python-list, we could just forgo the
filtering and pass on posts from all Discourse categories. But for
python-dev, the volume is too high, and existing python-dev subscribers
probably don't want a category like "Help".

Cheers,
Baptiste
___
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/JHWMPCWFUHQDHQM7NEPJYV2JINM37UAJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Baptiste Carvello]

Le 07/12/2022 à 11:57, Petr Viktorin a écrit :
> 
> I'd like to point out that the SC decision was *reactive*, after most
> discussions moved to Discourse without SC pushing.
> 
> I liked the list myself! But as soon as most of the posts were mandatory
> PEP and release notices, it stopped being useful.

Well, that's only taking into account the posting side. On the reading
side, I reckon that many more people (more or less) silently read
python-dev than Discourse.

Cheers,
Baptiste
___
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/PMPF3OJ22A54FZTJBXW4DSDUNXVDWBLV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Baptiste Carvello]

Le 07/12/2022 à 16:11, John Ehresman a écrit :
> I’ve found that using mailing list mode to lurk on discuss.python.org works 
> well. I’ve set up rules on my local mail client to archive what I don’t want 
> in my inbox; I have 4 rules in place now, though I’m interested in a bit more 
> than what was typically on python-dev.

I trust you that mailing list mode can work, once you've refined your
filter rules. Others have posted similar results.

However, each user writing their own filter rules doesn't scale well.
Most people just won't do it.

If this list really is to be shut down with no continuation, hopefully
we'll be given advance warning and allowed some more time to exchange
working, refined recipes.

Cheers,
Baptiste
___
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/O4QRFK36KBCV345GUDCV5DPKJXTU7QSA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Baptiste Carvello]

Hi,

Le 05/12/2022 à 14:50, Stephen J. Turnbull a écrit :
>
>  I'd be sad, but I get the feeling that the only people left
> reading it are "here for the community", not to develop code, …
I think this is indeed true, but that's nothing to be sad about: "being
here for the community" is not wrong or shameful.

Since forever, python-dev has attracted a large following of enthusiast
Python users, who want to understand the design choices of their
preferred language. This widely shared concern for writing idiomatic
code is a distinguishing trait of the Python community (the whole
culture of "pythonic" code).

Now maybe this is a place where the mailman devs could help and make a
real difference: what if this list would become, not archive-only, but a
*read-only mirror* of those parts of Discourse that are relevant for
core development? That would mean setting up a pipeline starting with
Discourse's so-called "mailing-list mode", going through the kind of
filter stack that some core developers have been setting up for their
personal use, and feeding into this mailing list. The last part can only
be done with the powers of the mailman admins.

Being read-only would not be a problem in practice: non core-devs here
read much more than they post (as they should). Being forced to log into
a specific website is an acceptable roadblock once in a while for
posting, just not every day for simply following the discussions.

Turning this list into a relevant mirror of Discourse is the nicest
course of action for the hundreds of silent readers python-dev has
gathered over the years. All those people *won't* switch to routinely
visiting the Discourse website, no matter how much pushing and wishful
thinking the Steering Council puts into it. Shutting down the list means
kicking them away, more or less overtly.

Cheers,
Baptiste
___
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/TXLKFNL3RUFNIU5DELXIJQF3UZOX6DIH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Baptiste Carvello]

Le 04/12/2022 à 16:55, Barney Gale a écrit :
> 
> I don't want to post to multiple
> places in order to reach the devs.

Nobody proposed that. In order to reach the devs, you use discourse (or
have someone else do it on your behalf).

Just let the "second circle" of the community keep their mailing list,
as this second circle just won't switch to a specialized, and quite
unflexible tool.

Yeah, without most core devs, this list might be more akin to
python-ideas than the old python-dev. But it makes sense to keep the
bigger following it has grown over the years.

> I prefer mailing lists personally, but theyve been losing out to web
> forums for 20 years now.

This is historically untrue. In technical communities, web forums have
been considered second class tools until some 5 years ago, with
mailing-lists being seen as lighter, more flexible and more capable.

Then they began loosing to *heavily moderated* web forums because of the
insistence on moderation. Yeah, smartphones with no capable mail client
played a role too.

Cheers,
Baptiste
___
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/A2667BXDXYU5TXG535IUSWI6WRC35DIB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Baptiste Carvello]

Le 02/12/2022 à 18:49, Brett Cannon a écrit :
> 
> Since we are promoting/pushing folks to use discuss.python.org

Until now I've seen more "pushing" (with sticks) than "promoting" (with
carrots).

Since august I've been looking for a way to follow the discussions on
discourse without using the heavy and annoying web interface, or
building a whole stack of filters on my side. It's annoyingly close to
working with RSS: "posts.rss" would just need to keep entries for a
longer time, and include category information.

I regret that there seems to be zero interest in fixing those last
glitches and making RSS really work.

>  it means this mailing list starts to feel
> like more of a burden/excess.

The "burden" of keeping one additional list on an existing platform is
moderate. Nobody would be forced to read it, but interesting ideas would
surely be copied over to discourse at some point.

All the death clamors are way premature, and either relate to the
"sticks" tactics, or to the usual intolerance of "modern tools" converts.

Baptiste
___
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/UT5T4PZ6KEB7EQXLK3ZE6ZK2U6S37AKT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Baptiste Carvello]

Le 02/12/2022 à 10:09, Gregory P. Smith a écrit :
> 
> On Thu, Dec 1, 2022 at 8:37 AM Victor Stinner  > wrote:
> 
> 
> Should we *close* the python-dev mailing list?
> 
> 
> I'd be in favor of this. 

Why? Californian firms won't let their employees use an unmoderated
forum for fear of liability: OK, so be it. But that's no reason to force
other people to use tools they dislike. "Modern tools" hegemonism is
little more than pure intolerance.

Or at least setting up an auto-responder
> suggesting people post on discuss.python.org 
> instead.

Just put a line in the list signature stating that discussions requiring
core-dev attention should happen on discourse, and be done.

Cheers,
Baptiste
___
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/IDKDF7P4WTNVZNJHJZIEQB2M42THOJ3V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Moving to Discourse

[Baptiste Carvello]

Hello,

I'm afraid you misundertood my message. I'm not discussing the choice of
Discourse as a communication medium (which would be futile after the
decision has been made), just the thematic perimeter that would make up
an equivalent of Python-dev (for those hundreds of us who happened to
like it).

Le 22/09/2022 à 19:58, Brett Cannon a écrit :
> On Thu, Sep 22, 2022 at 12:41 AM Baptiste Carvello
>  <mailto:devel2...@baptiste-carvello.net>> wrote:
> Le 21/09/2022 à 13:14, Petr Viktorin a écrit :

> > But I don't think the goal is to make sure all people using the mailing
> > list get the same set of posts. Different people have different 
> interests.

> That's exaggerated: often many people share common interests, and thus
> want to follow a common set of discussions.

> ... which is expected to take place on Discourse.
> [...]

"Discourse", without further qualification, is a discussion medium, not
a discussion forum as I mean it ("a group of people sharing common
interests…").

The Python discourse instance is the equivalent of Python-list +
Python-dev + Ideas + Typing + Packaging + whatever else. Nobody is
expected to read all of that, are they? Thus it makes sense to be
interested in a sensible subset of it.

> This is what makes up a
> discussion forum. Python-dev has served well its hundreds (or is it
> thousands) of users over all those years, so its perimeter must be
> sensible enough.

> But the mailing list has also not served others well either
> [...], so I don't think it "must be sensible enough" that
> what python-dev does is always best/right/sensible.
> [...]

My words "sensible enough" only qualified the *thematic perimeter* of
Python-dev: design discussions including PEPs, relation to other
important projects in the community, sometimes general programming
philosophy.

This perimeter is a product of experience. There's a reason Python-dev
was split from Python-list, then Ideas from Python-dev etc. Let history
inform us.

In conclusion, the only thing I'm looking for is a fully working way to
access this information perimeter from a convenient mail-like interface.
Various solutions have been handwaved, but none is ready for prime time.


> In the meantime, I suppose Discourse must have some instance
> configuration knobs, and it would make sense that the length of the RSS
> files can be changed there (being a very arbitrary limit). The PSF could
> then choose a more appropriate length just for their own instance (the
> current 25-post limit represents less than 24 hours; a few days instead
> would be nice).
> 
> 
> If you can find the setting then we can look at tweaking it, but a quick
> glance at the admin interface didn't turn up anything obvious.

Sorry to say, but this is yet another sign that Discourse is not mature
enough for a community as big as Python. This set-in-stone limit is
obviously devised for a very small community.

Cheers,
Baptiste
___
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/HHR6APCBEWQRPRDMF2JQGW6PCGEK7OWQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Moving to Discourse

[Baptiste Carvello]

Hello,

Le 21/09/2022 à 13:14, Petr Viktorin a écrit :
> On 21. 09. 22 10:17, Baptiste Carvello wrote:
>>
>> * mailing-list mode: there needs to be a *standardized* set of filters
>> to access Core-Dev + PEPs (and only that).
>> [...]

> Do you have a proposal we could standardize?
> Open a PR on the devguide. You shouldn't need an official hat-wearer
> around, unless there's a disagreement.

I believe indeed that the devguide should provide complete guidance
towards getting a python-dev equivalent using mailing-list mode, to
avoid many users having to reinvent the wheel. I don't have enough
experience to give such advice myself (yet).

> But I don't think the goal is to make sure all people using the mailing
> list get the same set of posts. Different people have different interests.

That's exaggerated: often many people share common interests, and thus
want to follow a common set of discussions. This is what makes up a
discussion forum. Python-dev has served well its hundreds (or is it
thousands) of users over all those years, so its perimeter must be
sensible enough.

> Only mirroring/archiving Core-Dev + PEPs also seems pretty arbitrary.

According to the devguide, "these are the Discourse equivalents to the
python-dev mailing list". I believe many people want just that. This is
also the perimeter that makes most sense for long term external
archival, as it is likely to contain all major design discussions.

>> * RSS: the shortcomings I described in my august post [2] are still
>> there. At the very least, the PSF needs to make sure that the age /
>> length limits of the RSS files (both core-dev.rss and posts.rss) are
>> *much* increased.

> I'm not sure what the PSF can do here -- this sounds like it should be a
> feature request to Discourse.

Discourse could indeed make their RSS interface much friendlier. Alas,
as I say in my previous message, a very useful feature request
(per-category post feeds) has been lingering for 6 years. So I won't
hold my breath.

In the meantime, I suppose Discourse must have some instance
configuration knobs, and it would make sense that the length of the RSS
files can be changed there (being a very arbitrary limit). The PSF could
then choose a more appropriate length just for their own instance (the
current 25-post limit represents less than 24 hours; a few days instead
would be nice).

> I guess the mailing list mode is a better option if you don't want to
> miss anything. Is it lacking something that RSS provides, besides easier
> filtering?

There is room between not missing anything and having less than 24 hours
of history available.

Since you asked (but not a major point): RSS is accessible without
registering an account.

Cheers,
Baptiste

>> [2]
>> https://mail.python.org/archives/list/python-dev@python.org/message/UZJ27G57F7QJJ2LYBDGZQ5BIXLH7OXWJ/
___
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/MBARP67IL4X3LUWQGEELTMFPJCLUXBTI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Moving to Discourse

[Baptiste Carvello]

Hello,

good to see that someone in the Steering Council still reads here, as
some of the actions necessary to make either mailing-list mode or RSS a
viable alternative [1] need an official "hat":

* mailing-list mode: there needs to be a *standardized* set of filters
to access Core-Dev + PEPs (and only that). That's the only way to make
sure all people using mailing-list mode get the same set of posts.
Giving this set of filters an official status would allow external
mirroring and archiving (relying solely on discourse.org for archiving
is imprudent).

* RSS: the shortcomings I described in my august post [2] are still
there. At the very least, the PSF needs to make sure that the age /
length limits of the RSS files (both core-dev.rss and posts.rss) are
*much* increased.

Cheers,
Baptiste

[1] hopefully "we don't see anything that would block Python
development" doesn't mean alternatives to the (slow and annoying) web
interface are abandoned.

[2]
https://mail.python.org/archives/list/python-dev@python.org/message/UZJ27G57F7QJJ2LYBDGZQ5BIXLH7OXWJ/

 Viktorin a écrit :
> As mentioned previously [0], the Steering Council decided to switch from
> python-dev to Discourse (discuss.python.org).
> We're aware that Discourse is not perfect. The previous mail thread [0]
> lists various shortcomings, as well as some workarounds. However, we
> don't see anything that would block Python development.
> 
> Practically, the switch means that:
> - New PEPs should be announced in the PEPs category on Discourse (rather
> than on this list), and
> - The Devguide will list Discourse, rather than mailing lists, as the
> primary communication channel.
> 
> Note that you can have development-related discussions anywhere, as long
> as you (eventually) include all relevant people. You're welcome to
> continue using python-dev and other mailing lists, IRC, in-person
> sprints, etc. But for PEP-level changes, we believe python-dev no longer
> reaches the proper audience.
> 
> For the related docs changes, see [peps-2775] and [devguide-945]. Note
> that this is documentation, not law – if something is unclear or doesn't
> make sense, please ask for clarification or propose edits.
> 
> [0]:
> https://mail.python.org/archives/list/python-dev@python.org/thread/VHFLDK43DSSLHACT67X4QA3UZU73WYYJ/
> 
> [peps-2775]: https://github.com/python/peps/pull/2775
> [devguide-945]: https://github.com/python/devguide/pull/945
> 
> 
> — Petr, on behalf of the Steering Council
> ___
> 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/NS5C6EPMNEUH7X64SSBAUKUDCWYHZGUT/
> 
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/6GQDLGC7NYBLIQWAX2GJ5L32TPIUVCOV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Baptiste Carvello]

Le 18/07/2022 à 13:45, Baptiste Carvello a écrit :
> Le 15/07/2022 à 17:52, Petr Viktorin a écrit :
>>
>> For everything on Discourse, the RSS feed is at
>> https://discuss.python.org/latest.rss
>> For a specific categoriy/topic, append .rss to the Web URL.
> 
> [...]
> Is there a way to access all posts through the mail/RSS client,
> preferably with a threaded view?

TL;DR: almost there, but not there yet. A few fixes are needed in
Discourse for RSS to become a viable reading strategy.

Hi all,

reviving this old thread to try and answer my own question. For the last
month (which included a ten-day vacation), I've tried using core-dev.rss
or posts.rss (with Thunderbird). Both give a very frustrating feeling of
"almost there, but definitely not there yet":

* core-dev.rss: does its job at listing which topics get discussed. The
first post is usually enough to decide whether I'm interested or not.
Being a web browser below the surface, Thunderbird even has a "web page
mode" that permits reading the discourse thread page embedded in it
(much slower that text, but surprisingly without nag screens).

Except that threads older than a few days are scrubbed from the rss
file, even when the thread continues. So when I come back from vacation,
I not only lose past discussions (which is fair game), but also still
current ones.

Also, core-dev.rss can provide no indication when new activity happens
on a given thread, so I have to reopen them all in "web page mode"
(slow) just to check.

* posts.rss: can be used efficiently together with Thunderbird's sorting
features. I first sort by "date" to find current discussions, select an
interesting post, them sort by "object" to see the full thread.

The problem is with the volume. Not only are all messages included, but
Discourse doesn't provide the "category" rss tag, which Thunderbird
could use to tag the messages.

Adding a per-category posts.rss has been a feature request to Discourse
since 2016 [1], but "hasn’t happened yet", as the Discourse developers
put it. No patch was asked for, so I presume they just see the use case
as very unimportant.

[1]: https://meta.discourse.org/t/rss-feed-for-category-latest/37192

Perhaps someone with an official status in the Python community could
approach the Discourse developers and weight in so that:

* still current threads are not so aggressively scrubbed from core-dev.rss;

and/or
* "category" tags are added to posts.rss;

and/or
* per-category posts.rss are finally implemented.

Cheers,
Baptiste
___
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/UZJ27G57F7QJJ2LYBDGZQ5BIXLH7OXWJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Baptiste Carvello]

Le 21/07/2022 à 07:59, Stefan Behnel a écrit :
> 
> I'm actually reading python-dev, c.l.py etc. through Gmane, and have
> done that ever since I joined. Simply because it's a mailing list of
> which I don't need a local (content) copy, and wouldn't want one. Gmane
> seems to have a complete archive that's searchable, regardless of "when
> I subscribed".
> 
> It's really sad that Discourse lacks an NNTP interface. […]

+1000

For this switch to accommodate all use cases, Discourse really needs a
"lurking" story.

That's lacking right now, possibly by design (Discourse developers are
quite opinionated*, and anonymous reading seemingly doesn't fit their
worldview). Maybe they can be convinced, though…

By the way, I'm still trying the RSS way, but it doesn't seem to fit the
bill (lack of a stream of posts per category).

Cheers,
Baptiste

*not meant as a criticism: opinionated is good; it just makes it more
difficult to provide the main communication channel of a wide and
diverse community.
___
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/L3FCN6MMRCWD5SFCJOPDSCIKEG7IRFQL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Baptiste Carvello]

Le 21/07/2022 à 03:29, Stephen J. Turnbull a écrit :
> 
> I can't speak to 1 and 2, and I can't speak to cost of resource usage
> for 3, but it would be possible to have a Mailman list that has no
> subscribers, prohibits subscription, and allows only a small number of
> authorized posters, one of which would be the Discourse mail feed.

Hi,

If GMANE would be allowed to subscribe, that would be a perfect fit!

Cheers,
baptiste
___
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/65XLUOBUJEN4UG6IXHHBYSZRTVCE22DT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [SPAM] Re: Switching to Discourse

[Baptiste Carvello]

Le 15/07/2022 à 17:52, Petr Viktorin a écrit :
> 
> For everything on Discourse, the RSS feed is at
> https://discuss.python.org/latest.rss
> For a specific categoriy/topic, append .rss to the Web URL.

Hello,

thanks for the useful information.

However, I just tried it and I can only read the first message of each
thread. Then I have to "Read full topic" through the nightmarish web
interface with its nag screens.

Is there a way to access all posts through the mail/RSS client,
preferably with a threaded view?

Cheers,
Baptiste
___
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/AJBR4SD7I5D66XXOGYMWMUMHSP764H63/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About PEPs being discussed on Discourse

[Baptiste Carvello]

Hi,

Le 08/04/2022 à 15:34, Petr Viktorin a écrit :
> 
> I follow Discourse by e-mail, in the "Mailing list mode", where
> Discourse sends me all comments and I filter in the e-mail client. That
> works rather well for me.

If this is so, is there a possibility to funnel the message stream
through GMANE (or some similar list archive), for the benefit of casual
readers?

(And no, the Discourse web interface without logging in just doesn't cut
it for casual reading. You can't read a whole thread without being
interrupted by nag screens "You seem to be interested etc…". And you
can't remember what you already read and what not.)

Cheers,
Baptiste
___
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/FIS4GHPEBM3M6HYCN72I63JL73AKYMNN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About PEPs being discussed on Discourse

[Baptiste Carvello]

Hi,

Le 08/04/2022 à 03:52, David Mertz, Ph.D. a écrit :
> FWIW, I find Discourse (and everything similar that I've seen), awkward,
> difficult to use, poorly organized, and in every way inferior to my mail
> client.

Another Discourse misfeature I just came across: history rewriting. I
know it's by design, but, at least for casual readers, it makes it hard
to know which information is new.

Concrete case: the GitHub Issues transition post (
https://discuss.python.org/t/github-issues-migration-is-coming-soon/13791 )
is displayed as a "read" link in my browser for more than a month.
Still, I just found out that it was edited twice in between. How am I
supposed to know?

Just as a data point,
Baptiste
___
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/53QL5TFMIDFUJ5U2XEXVN2543VEXJY6E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Baptiste Carvello]

Le 28/03/2022 à 18:44, Steve Dower a écrit :
> I think to most people "batteries included" doesn't necessarily mean
> "standard library," with all that implies. It just means "it came with
> the first thing that I installed" (or alternatively, "at no additional
> charge").

A point I have not seen made, is that some uses really need *standard*
batteries.

In scientific research, you'll sometimes share a data-processing script
among a large group of non-computer-specialists, who hopefully all have
*some* Python+NumPy installed: it may be a full up-to-date Conda, or it
may be "a very old version that a former colleague installed for me
years ago and now I won't update it for fear I break it". You have to
cater to all versions.

It may be more glamorous to compete with Rust and JS for "best modern
language", than with Excel for "lowest common denominator for
calculation". Still, that's a use case where Python has historically
been strong, and it's one of the reasons it works so well in the
research world.

Hopefully this use case is not forgotten, even if those
non-computer-specialists users are less likely to be involved here in
core development.

Cheers,
Baptiste
___
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/V4QX4ZSHSUUMVQR3CRAEMBBR6N3WGVLM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

[Baptiste Carvello]

Hello,

Le 21/10/2021 à 07:59, Steven D'Aprano a écrit :
> 
> Versions of this that rely on catching AttributeError are simply wrong 
> and are an anti-pattern. They catch too much and silently turn 
> errors into silent wrong behaviour.
>  
> PEP 505 does not fall into that trap.

This is not true as a general rule: the PEP 505 examples with
`dict.get()` do catch too much.

Also, if `None` is not special, you are free to make up your own
`NoValue` sentinel object, which can raise specific exceptions on
attribute access, item access, etc:

class NoValueError(Exception):
  pass

class NoValueAttributeError(AttributeError, NoValueError):
  pass

and so on…

So this particular point seems solvable.

Cheers,
Baptiste
___
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/J4R3QHH7GNMJAP6VPP2LVXMAAO2YAKU2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

[Baptiste Carvello]

Le 18/10/2021 à 20:26, Guido van Rossum a écrit :
> 
> y = None  # Default
> if config is not None:
>   handler = config.get("handler")
>   if handler is not None:
>     parameters = handler.get("parameters")
>     if parameters is not None:
>   y = parameters.get("y")
> 
> […]
> Using ?. this can be written as
> 
> y = config?.get("handler")?.get("parameters")?.get("y")

Sure, but the EAFP version is not that bad:

try:
  y = config["handler"]["parameters"]["y"]
except KeyError:
  y = None

which could be further simplified with an exception-catching expression
(caveat: keyword usage is pure improvisation, it sounds good, but is
probably broken :-) :

y = config["handler"]["parameters"]["y"] with KeyError as None

The PEP authors would probably reject this as "hiding errors in code",
which is true, but none-aware operators also hide errors…

Cheers,
Baptiste
___
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/JWZ2ZG7AIXXWDGNPUZDVLORDFMMEP3XV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 467 feedback from the Steering Council

[Baptiste Carvello]

Le 13/09/2021 à 19:01, Barry Warsaw a écrit :
> There is some discussion going on in bpo-45155 about what the default value 
> of the `byteorder` argument should be for int.to_bytes() and int.from_bytes():

Hello,

a use case and feature request:

I have used int.to_bytes() and int.from_bytes() interactively at the
Python REPL for picking apart pieces of binary data files, in contexts
of debugging or casual reverse-engineering (I could have used `struct`,
but then I would have needed to reread the doc ;-)

For this use case, setting defaults for the arguments is obviously
beneficial (less typing), and the most comfortable defaults would be:

- for `length`, the minimum length needed to encode the integer (I
mostly care for the content, not the leading or trailing zeros);

- for `byteorder`, preferably a fixed default so I can remember it once
and for all, and in any case something rather than None (if the bytes
are reversed, I'll still recognize them).

Whatever comes out of this discussion, it would be nice if the
`byteorder` constants got a one-character short form, be it 'l' and 'b'
for discoverability, or '<' and '>' for consistency with `struct`.
Having to type 'little' is painfully long at the REPL.

Cheers,
Baptiste
___
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/7ZTUJDMSJEBLORSTHV6X6DZVESIKOKKL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

[Baptiste Carvello]

Hi,

I'm afraid we are talking past each other. In my case, the applications
are either part of my Python-based work setup, which needs to be rebuilt
anyway in the very infrequent occurrence of a major Python upgrade (I
could get away with using the system python for that on a "stable" distro).

Or they are installed using my distro's package manager, which takes
care of upgrading dependent packages together. This is the classical
"DLL hell" problem, right? Or is there some Python specificity that I
don't get?

Cheers,
Baptiste

Le 21/06/2021 à 20:20, Guido van Rossum a écrit :
> Okay, I think your evidence can then be discounted. Really, any app that
> relies on the publicly installed Python runs a serious risk of breaking
> when that Python gets updated, regardless of whether the ABI changes or not.
> 
> On Mon, Jun 21, 2021 at 2:46 AM Baptiste Carvello
>  <mailto:devel2...@baptiste-carvello.net>> wrote:
> 
> Hi,
> 
> Le 18/06/2021 à 21:00, Guido van Rossum a écrit :
> > Can you elaborate on that use case? Which two applications are you
> > thinking of, and what was your goal in driving them? This sounds
> > interesting but I haven’t encountered this myself.
> 
> Well, I'm not sure the case I was thinking of is still relevant to
> anything: that was plotting 3D crystal models using crystallography
> library CCTBX [1] and visualization application Mayavi [2], some 15-20
> years ago. BTW, I misremembered a bit: only CCTBX insisted on using a
> vendored python ("libtbx.python"), Mayavi used the system python.
> Anyway, it was more pain to make Mayavi use libtbx.python, than to make
> CCTBX work with the system python.
> 
> Also, I must admit that even applications embedding the system python
> can have some limitations. For example, GIMP and GDB can execute python
> scripts, but their API can't be "imported" from the outside. Which means
> no arguments passed to the script over the command line ("sys.argv"), no
> venvs, no REPL. But at least you can install additional packages (pip /
> distro package manager) and limitations can be more or less hacked
> around. For a sophisticated example, the debugger extension Voltron [3]
> provides REPL access to GDB objects over a client-server connexion.
> 
> Cheers,
> Baptiste
> 
> [1] https://cci.lbl.gov/docs/cctbx/
> [2] https://docs.enthought.com/mayavi/mayavi/
> [3] https://github.com/snare/voltron
> 
> > On Fri, Jun 18, 2021 at 09:44 Baptiste Carvello
> >  <mailto:devel2...@baptiste-carvello.net>
> > <mailto:devel2...@baptiste-carvello.net
> <mailto:devel2...@baptiste-carvello.net>>> wrote:
> >
> >     Le 18/06/2021 à 08:50, Paul Moore a écrit :
> >     >
> >     > IMO it doesn't. However for certain applications (the sort
> of thing I
> >     > was referring to) - where the user is writing their own
> scripts and
> >     > the embedding API is used merely to expose an interface to
> the Python
> >     > language, dynamically linking to whatever version of Python
> the user
> >     > has installed can be precisely the right thing to do - the
> user gets
> >     > access to the version of the language they expect, the installed
> >     > packages they expect to see, etc.
> >
> >     As a user, I second this. When trying to drive applications
> from the
> >     outside (as opposed to extending them through plugins), it is
> annoying
> >     when two applications won't work together because each one
> insists on
> >     using its own vendored python.
> >
> >     Of course, there are often real blockers, such as incompatible
> event
> >     loops. But not always…
> >
> >     Cheers,
> >     Baptiste
> >     ___
> >     Python-Dev mailing list -- python-dev@python.org
> <mailto:python-dev@python.org>
> >     <mailto:python-dev@python.org <mailto:python-dev@python.org>>
> >     To unsubscribe send an email to python-dev-le...@python.org
> <mailto:python-dev-le...@python.org>
> >     <mailto:python-dev-le...@python.org
> <mailto: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/PPKL7466BIG6DPCUIJ

[Python-Dev] Re: Roundup to GitHub Issues migration

[Baptiste Carvello]

Hi,

Le 21/06/2021 à 23:31, Christopher Barker a écrit :
> 
>   >  [...] Github is a
>   >  developers' social network, "mere" users are much less likely to want to
>   >  be part of it. [...]
> 
> 
> But you don’t need to be “part of it” in any meaningful way. One only
> needs to create an account, which could be quite anonymous, and even
> temporary.

I don't believe you can actually use temporary accounts. Github only
allows one account per physical person, and if I delete my account, then
later open a new one from the same IP and/or with a related e-mail
address, I would expect them to either blocklist me, or resurrect the
old account and copy the data to the new one. If anyone really tried,
please correct me.

> [...]
> Also: cPython is a large, complex, and mature project. I don't think
> many non-developers can even identify a true bug, much less write a
> helpful big report. [...]

There is a genuine question here: bluntly said, are bug reports still
welcome? In the tradition of the Free Software movement, reporting bugs
is considered an act of good citizenship. If the scarcity of developer
time makes it no longer be the case for cPython, it'd rather be broadly
communicated to users.

> [...] I don’t mind needing an account to
> contribute to a conversation.

I do, if a single company becomes the gatekeeper of most conversations
in a whole field of endeavor. Alas, I have to admit being in the
minority, so let this part of the discussion rest.

Cheers,
Baptiste
___
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/J356YY7BI3IFPRZ44PHKIV2MNDIXSUQZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

[Baptiste Carvello]

Hi,

Le 21/06/2021 à 13:48, Victor Stinner a écrit :
> Hi,
> 
> As a bug triager, it's very frustrating when I ask for more
> information about a bug, and I get no reply. Usually, such bug is
> closed as "out of date" (lack enough information to be debugged).

There seems to be an untold assumption that non-github-users are more
likely to not reply to their own bugs. Not sure why, I may lack context.

> The requirement for a GitHub account was well known when PEP 581 was
> accepted. The PEP was approved. It's now time to move on!

PEP 588 has been saying the exact opposite for 2 years (maybe they did
not really mean it, but that's what's written).

> [...]

> It's all about trade-offs. Don't under estimate the cost of operating
> our own bug tracker. System administration is not free.

Note, however, that requiring a github account for reporting bugs is a
whole different trade-off than requiring it for development. The second
makes python an unwelcoming project for privacy-conscious people, but I
understand that such is the price to pay for more efficient freeware
tools. And it's an already made choice anyway.

By contrast, requiring a github account for reporting bugs also makes
python an unwelcoming place for non-developers in general. Github is a
developers' social network, "mere" users are much less likely to want to
be part of it. Many will just silently abandon their bug report.

Cheers,
Baptiste

> 
> Victor
> 
> On Mon, Jun 21, 2021 at 11:46 AM Baptiste Carvello
>  wrote:
>>
>> Hi,
>>
>> Le 21/06/2021 à 04:20, Ezio Melotti a écrit :
>>> This effort is being tracked at
>>> <https://github.com/psf/gh-migration/projects/1>: this board reflects
>>> the current status of the project.  The PEPs (including PEP 588 --
>>> GitHub Issues Migration Plan) haven't been updated yet and might
>>> contain outdated information, so please refer to the psf/gh-migration
>>> repo for the latest updates.
>>
>> since 2019, I've been waiting for proposed solutions to PEP 588's first
>> open issue ("A GitHub account should not be a requirement"). Now would
>> be the time to think about it, but I see no such reflection mentioned in
>> the repo.
>>
>> Cheers,
>> Baptiste
>> ___
>> 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/2GJQKB27XD6LKGKWJXTXLEURNMF5ZJT7/
>> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> 

___
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/ETQO4M3IUCXATK2UL56PSYE6FZPNZHIY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

[Baptiste Carvello]

Hi,

Le 18/06/2021 à 21:00, Guido van Rossum a écrit :
> Can you elaborate on that use case? Which two applications are you
> thinking of, and what was your goal in driving them? This sounds
> interesting but I haven’t encountered this myself.

Well, I'm not sure the case I was thinking of is still relevant to
anything: that was plotting 3D crystal models using crystallography
library CCTBX [1] and visualization application Mayavi [2], some 15-20
years ago. BTW, I misremembered a bit: only CCTBX insisted on using a
vendored python ("libtbx.python"), Mayavi used the system python.
Anyway, it was more pain to make Mayavi use libtbx.python, than to make
CCTBX work with the system python.

Also, I must admit that even applications embedding the system python
can have some limitations. For example, GIMP and GDB can execute python
scripts, but their API can't be "imported" from the outside. Which means
no arguments passed to the script over the command line ("sys.argv"), no
venvs, no REPL. But at least you can install additional packages (pip /
distro package manager) and limitations can be more or less hacked
around. For a sophisticated example, the debugger extension Voltron [3]
provides REPL access to GDB objects over a client-server connexion.

Cheers,
Baptiste

[1] https://cci.lbl.gov/docs/cctbx/
[2] https://docs.enthought.com/mayavi/mayavi/
[3] https://github.com/snare/voltron

> On Fri, Jun 18, 2021 at 09:44 Baptiste Carvello
>  <mailto:devel2...@baptiste-carvello.net>> wrote:
> 
> Le 18/06/2021 à 08:50, Paul Moore a écrit :
> >
> > IMO it doesn't. However for certain applications (the sort of thing I
> > was referring to) - where the user is writing their own scripts and
> > the embedding API is used merely to expose an interface to the Python
> > language, dynamically linking to whatever version of Python the user
> > has installed can be precisely the right thing to do - the user gets
> > access to the version of the language they expect, the installed
> > packages they expect to see, etc.
> 
> As a user, I second this. When trying to drive applications from the
> outside (as opposed to extending them through plugins), it is annoying
> when two applications won't work together because each one insists on
> using its own vendored python.
> 
> Of course, there are often real blockers, such as incompatible event
> loops. But not always…
> 
> Cheers,
> Baptiste
> ___
> Python-Dev mailing list -- python-dev@python.org
> <mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-le...@python.org
> <mailto: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/PPKL7466BIG6DPCUIJURLE5ZGFNHBNSM/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> -- 
> --Guido (mobile)
> 

___
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/KP3SE6UWSV3VDCJOWCXUZIBPDWFJHRLU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

[Baptiste Carvello]

Hi,

Le 21/06/2021 à 04:20, Ezio Melotti a écrit :
> This effort is being tracked at
> : this board reflects
> the current status of the project.  The PEPs (including PEP 588 --
> GitHub Issues Migration Plan) haven't been updated yet and might
> contain outdated information, so please refer to the psf/gh-migration
> repo for the latest updates.

since 2019, I've been waiting for proposed solutions to PEP 588's first
open issue ("A GitHub account should not be a requirement"). Now would
be the time to think about it, but I see no such reflection mentioned in
the repo.

Cheers,
Baptiste
___
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/2GJQKB27XD6LKGKWJXTXLEURNMF5ZJT7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

[Baptiste Carvello]

Le 18/06/2021 à 08:50, Paul Moore a écrit :
> 
> IMO it doesn't. However for certain applications (the sort of thing I
> was referring to) - where the user is writing their own scripts and
> the embedding API is used merely to expose an interface to the Python
> language, dynamically linking to whatever version of Python the user
> has installed can be precisely the right thing to do - the user gets
> access to the version of the language they expect, the installed
> packages they expect to see, etc.

As a user, I second this. When trying to drive applications from the
outside (as opposed to extending them through plugins), it is annoying
when two applications won't work together because each one insists on
using its own vendored python.

Of course, there are often real blockers, such as incompatible event
loops. But not always…

Cheers,
Baptiste
___
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/PPKL7466BIG6DPCUIJURLE5ZGFNHBNSM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[Baptiste Carvello]

Le 11/05/2021 à 09:35, Steven D'Aprano a écrit :
> On Mon, May 10, 2021 at 09:44:05PM -0400, Terry Reedy wrote:
> 
>> The vanilla interpreter could be updated to recognize when it is running 
>> on a similated 35-year-old terminal that implements ansi-vt100 color 
>> codes rather than a similated 40+-year-old black-and-white teletype-like 
>> terminal.
> 
> This is what is called "scope creep", although in this case 
> perhaps "scope gallop" is more appropriate *wink*
> [...]

Also: people paste tracebacks into issue reports, so all information has
to survive copy-pasting.

Cheers,
Baptiste
___
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/U2U44ZB3HFBAD3TGJ5X7Q3P6QCAIRYG2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Baptiste Carvello]

Hi,

sorry for being late to the party, but I may not be the only one wondering…

Le 14/04/2021 à 20:56, Barry Warsaw a écrit :
> 
> I’d forgotten that this PEP was in Deferred state.  I think it should be 
> rejected and I plan on making that change.  importlib.metadata is a much 
> better approach to programmatically determining package versions.
> 
> https://docs.python.org/3/library/importlib.metadata.html#distribution-versions

This is indeed the correct approach, thanks for letting me learn this.

However, I unsuccessfully searched for the canonical way to look up the
distribution name based on either a module name or an imported module
object. Is there one?

Looks like it could be computed based on information in
"*.egg-info/installed-files.txt", but it's far from trivial. Is
"installed-files.txt" even guaranteed to exist for all distributions?

Cheers,
Baptiste
___
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/SVQ777EGE56OIWHIKPCURGPXGMUJ7HCY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Baptiste Carvello]

Hi,

Le 14/04/2021 à 19:44, Guido van Rossum a écrit :
> 
> No, what I heard is that, since in *most* cases the string quotes are
> not needed, people are surprised and annoyed when they encounter cases
> where they are needed. And if you have a large code base it takes an
> expensive run of the static type checker to find out that you've
> forgotten the quotes.

Well, I had assumed quotes would be used in all cases for consistency.
Indeed, using them only if needed leads to surprises. Are there specific
annoyances associated with quoting always, apart from the 2 more characters?

>  
> [...]
> 
> They will treat it as anything else they don't quite understand -- they
> will ignore it unless it bites them. And the rule for finding the end of
> an annotation would be very simple -- just skip words until the next
> comma, close paren or colon, skipping matching brackets etc.

That's assuming the syntax in the annotations doesn't diverge too much
from the Python syntax as far as brackets etc are concerned. I must say
I'm not too worried about typing. But the hypothetic "def foo(prec:
--precision int):" is already less readable. Will finding the closing
comma or colon always be obvious to the human reader?

Cheers,
Baptiste
___
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/E654LKI36TFURBOSBMFUPEMLJQ32CZNN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Baptiste Carvello]

Hi,

tl;dr: imho the like or dislike of PEP 563 is related to whether people
intend to learn a second syntax for typing, or would rather ignore it;
both groups should be taken into account.

Le 13/04/2021 à 19:30, Guido van Rossum a écrit :
> On Tue, Apr 13, 2021 at 9:39 AM Baptiste Carvello
>  <mailto:devel2...@baptiste-carvello.net>> wrote:
> 
> Then, what's wrong with quoting? It's just 2 characters, and prevent the
> user (or their IDE) from trying to parse them as Python syntax.
> 
> 
> Informal user research has shown high resistance to quoting.

OK, but why? I'd bet it's due to an "aesthetic" concern: for typing
users, type hints are code, not textual data. So it irks them to see
them quoted and syntax-highlighted as text strings.

> As a comparison: docstrings do get quoting, even though they also have
> special semantics in the language.
> 
> 
> Not the same thing. Docstrings use English, which has no formal (enough)
> syntax. The idea for annotations is that they *do* have a formal syntax,
> it just evolves separately from that of Python itself.

If I may say it in my words: to both the parser and (more importantly)
typing-savvy developers, type hints are code. I now see the point.

But what about developers who won't learn this (future) incompatible
typing syntax, and only encounter it in the wild? To them, those
annotations are akin to docstrings: pieces of textual data that Python
manages specially because of their role in the greater ecosystem, but
that they can ignore because the program behavior is not modified.

So it will irk them if annotations in this new syntax are not quoted or
otherwise made distinguishable from code written in the normal Python
syntax they understand. Again the "aesthetic" concern, and imho it
explains in large part why some people dislike PEP 563.

Can the needs of both groups of developers be addressed? Could code in
the new typing syntax be marked with a specific syntactic marker,
distinguishing it from both normal Python syntax and text strings? Then
this new marker could also be used outside of annotations, to mark
analysis-time-only imports or statements?

Or is this all not worth the expense, and typing syntax can manage to
stay compatible with normal Python syntax, in which case PEP 649 is the
way to go?

Cheers,
Baptiste
___
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/YI3DPTJXKTKZRVVWBJ6UYTUH3PPAJM6Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Baptiste Carvello]

Hi,

Le 12/04/2021 à 03:55, Larry Hastings a écrit :
> 
> I look forward to your comments,

2 reading notes:

* in section "Annotations That Refer To Class Variables":

> If it's possible that an annotation function refers
> to class variables--if all these conditions are true:
>
> * The annotation function is being defined inside
>   a class scope.
> * The generated code for the annotation function
>   has at least one ``LOAD_NAME`` instruction.

I'm afraid I don't really understand the second condition. Would it be
possible to rephrase it in a less technical way, i.e. some condition on
the user code itself, not on what the implementation does with it.

* in section "Interactive REPL Shell":

> For the sake of simplicity, in this case we forego delayed evaluation.

This has the unpleasant consequence that any code using forward
references cannot be copy-pasted into the REPL. While such copy-pasting
is a very casual practice and does already often break, it is sometimes
useful in quick'n dirty prototyping. Would it be possible to specify
that in this case, a possible NameError in evaluation is caught, and the
annotation is set to None or some sentinel value?

Cheers,
Baptiste
___
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/IPIJKJ6F4D634XT5ZXIKLD574QNWS2YB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Baptiste Carvello]

Hi,

Le 13/04/2021 à 04:24, Guido van Rossum a écrit :
> I've been thinking about this a bit, and I think that the way forward is
> for Python to ignore the text of annotations ("relaxed annotation
> syntax"), not to try and make it available as an expression.

Then, what's wrong with quoting? It's just 2 characters, and prevent the
user (or their IDE) from trying to parse them as Python syntax.

As a comparison: docstrings do get quoting, even though they also have
special semantics in the language.

Cheers,
Baptiste
___
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/V66L56SNJRUSM7CIJVCJDIPNHNZTGMWJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: On the migration from master to main

[Baptiste Carvello]

Le 25/03/2021 à 15:59, Stefano Borini a écrit :
> On Tue, 23 Mar 2021 at 21:39, Python Steering Council
>  wrote:
>> This isn’t just about ‘master’ being rooted in slavery.
> 
> No it's not and I am shocked that such ignorance would exist to believe that.

It is indeed not, but the peculiar bitkeeper/git usage is.

If both sides would agree on this, we could finally move on.

Cheers, Baptiste
___
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/D62N37HAFWYTXTRB5U5AQQBX3F2ODZ6C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Baptiste Carvello]

Hi,

Le 05/03/2021 à 14:46, Irit Katriel via Python-Dev a écrit :
> 
> 
> Whether you have "as" or not, the value of sys.exc_info() (which is what
> would be attached as the context to anything you raise in the except
> block) is the same. So these are not two different cases -- the only
> difference is whether or not you have a local variable set to
> sys.exc_info().

I don't really understand how this contradicts the behavior I proposed
(i.e. that bare "raise" raises something else than what is bound to the
"as" variable).

Specifically, which of the following statements are hard and unbreakable
rules, even when exception groups are involved:

1) sys.exc_info() must be the same object that is bound to the "as"
variable, if any;

2) sys.exc_info() must be the same object that is attached as __context__;

3) sys.exc_info() must be the same object that is raised by a bare "raise".

I'd say 1 is a hard rule because both objects are visible to user code,
so backwards compatibility applies. Rules 2 and 3, however, are internal
to the exception handling machinery, so I'm not so sure.

Cheers,
Baptiste

> On Thu, Mar 4, 2021 at 4:46 PM Baptiste Carvello
>  <mailto:devel2...@baptiste-carvello.net>> wrote:
> 
> Hi,
> 
> I'll take a shoot at this, just to see how it tastes… So, let's say:
> 
> When an exception group reaches a set of traditional "except" clauses,
> those are examined one after the other, in the order they are in the
> code. That way, exceptions matched by several clauses will cause the
> first one to run, same as today.
> 
> A subgroup is built with the subset of exceptions matched by the
> examined clause, as the PEP specifies for "except*". If this subgroup is
> None, the clause is not selected, and the next clause, if any, is
> examined. On the contrary, if the subgroup contains at least one matched
> exception, the clause is selected and no other clause will run (again,
> same as today). Exceptions not part of the subgroup are discarded.
> 
> The clause body is then run just once (so the boss only gets one email
> about KeyboardInterrupt). If the clause uses the "as" form, the "as"
> variable is bound to one exception in the subgroup, which one is
> unspecified (at least for now). The other ones are discarded, except if
> a bare "raise" is reached (below).
> 
> If a bare "raise" is reached while executing the body, the selected
> subgroup propagates out of the "try-except" construct. Justification:
> the whole group cannot propagate, because today a bare "raise" cannot
> reraise exceptions of a type not matched by the clause. However, if a
> single-type exception group is handled similar to a single exception in
> traditional "except" clauses, it is acceptable to let it propagate.
> 
> So you would have:
> 
> try:
>     g=BaseExceptionGroup(
>         [ValueError(), KeyboardInterrupt(), KeyboardInterrupt()])
>     raise g
> except RuntimeError:               # doesn't match
>     log_the_error()
> except  KeyboardInterrupt as e: # builds s=g.subgroup(KeyboardInterrupt)
>     email_the_boss(e)           # tells the boss of any one error
>     raise                       # reraises s
> except BaseException:           # would match, but doesn't run
>     launch_nuclear_attack()
> 
> # BaseExceptionGroup([KeyboardInterrupt(), KeyboardInterrupt()])
> # propagates further, a traditional "except KeyboardInterrupt"
> # would catch it. The ValueError is discarded.
> 
> An interesting feature would be: when the matching clause has no "as",
> "except" behaves the same as "except*", apart from the fact that only
> one clause may run.
> 
> Cheers,
> Baptiste
> ___
> Python-Dev mailing list -- python-dev@python.org
> <mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-le...@python.org
> <mailto: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/EXC6BQVHQXUXBHIEWHLSLU6FY7SJKIF3/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 

___
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/LXAATJDDWXYYQ3P62SAZ4H7CEZGX2TUW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Baptiste Carvello]

Le 03/03/2021 à 23:49, Irit Katriel via Python-Dev a écrit :
> 
> On Wed, Mar 3, 2021 at 10:39 PM Greg Ewing  > wrote:
> 
> [...]
> In other words, the only difference between except and
> except* would be that multiple except* clauses can be run,
> whereas only one except clause will run (the first one that
> matches something in the ExceptionGroup).
> 
> Is there any good reason not to do things that way?
> 
> That's an interesting idea. 
> 
> Do you mean that one exception gets handled and the rest of the group is
> reraised? Or discarded?
> [...]

Hi,

I'll take a shoot at this, just to see how it tastes… So, let's say:

When an exception group reaches a set of traditional "except" clauses,
those are examined one after the other, in the order they are in the
code. That way, exceptions matched by several clauses will cause the
first one to run, same as today.

A subgroup is built with the subset of exceptions matched by the
examined clause, as the PEP specifies for "except*". If this subgroup is
None, the clause is not selected, and the next clause, if any, is
examined. On the contrary, if the subgroup contains at least one matched
exception, the clause is selected and no other clause will run (again,
same as today). Exceptions not part of the subgroup are discarded.

The clause body is then run just once (so the boss only gets one email
about KeyboardInterrupt). If the clause uses the "as" form, the "as"
variable is bound to one exception in the subgroup, which one is
unspecified (at least for now). The other ones are discarded, except if
a bare "raise" is reached (below).

If a bare "raise" is reached while executing the body, the selected
subgroup propagates out of the "try-except" construct. Justification:
the whole group cannot propagate, because today a bare "raise" cannot
reraise exceptions of a type not matched by the clause. However, if a
single-type exception group is handled similar to a single exception in
traditional "except" clauses, it is acceptable to let it propagate.

So you would have:

try:
g=BaseExceptionGroup(
[ValueError(), KeyboardInterrupt(), KeyboardInterrupt()])
raise g
except RuntimeError:   # doesn't match
log_the_error()
except  KeyboardInterrupt as e: # builds s=g.subgroup(KeyboardInterrupt)
email_the_boss(e)   # tells the boss of any one error
raise   # reraises s
except BaseException:   # would match, but doesn't run
launch_nuclear_attack()

# BaseExceptionGroup([KeyboardInterrupt(), KeyboardInterrupt()])
# propagates further, a traditional "except KeyboardInterrupt"
# would catch it. The ValueError is discarded.

An interesting feature would be: when the matching clause has no "as",
"except" behaves the same as "except*", apart from the fact that only
one clause may run.

Cheers,
Baptiste
___
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/EXC6BQVHQXUXBHIEWHLSLU6FY7SJKIF3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

[Baptiste Carvello]

Hi,

Le 23/11/2020 à 01:41, Greg Ewing a écrit :
> On 23/11/20 7:49 am, Daniel Moisset wrote:
>> Look at the following (non-pattern-matching) snippet:
>>
>>     event = datetime.date(x, month=y, day=z)
> 
> The only names that are treated as lvalues there are to the left
> of an '='. […]
This is a crucial point for me as well. Especially "month=y" meaning
assign from month to y in "case datetime.date(x, month=y, day=z)" still
feels really weird, even after reading it times and again in this
many-month-old discussion. Sure, people who use pattern matching daily
will get used to it, but what about those who only use it once in a while?

I say this as someone who fully appreciates the parallelism between a
pattern and the corresponding constructor, and the elegance of this
design choice. The rational me likes it, but the instinctive me can't
get comfortable with its consequences ;-)

If it can be done, replacing the "=" sign with "as" feels like a good
compromise: the parallelism is still there, with just enough difference
to stand out.

Cheers,
Baptiste
___
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/P2OIXVBAPR7RDBJJA4DZICO3ZAJYP53E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Baptiste Carvello]

Hi,

Le 12/11/2020 à 18:55, Guido van Rossum a écrit :
> The position of PEP 622/634/535/636 authors is clear: 

well, let me first emphasize that I did *not* mean to reopen the
discussion on those PEPs, which explain and discuss their design choices
thoroughly (even better since the rewrite, thanks for that). And I
definitely did not mean to spawn another "mark capture or value"
subthread… I thought "PEP 642 v2" in the thread title was explicit
enough, should have been more cautious :-)

PEP 642 states as a design principle that parallelism between patterns
and assignments should be kept as much as possible (let's not discuss
this principle here). Thus, introducing different semantics for dotted
names deserves a discussion in that PEP (by contrast, literal
constraints need little discussion, because they have no semantics in
assignments).

> we see this as a
> necessary feature to support using enums (e.g. Color.RED) or constants
> defined in other modules (e.g. re.I) when simple switch functionality is
> being migrated from literals (e.g. case 404) to named constants (e.g.
> case HTTPStatus.NOT_FOUND). Bothering users with the technicality of
> needing to use '==' here is a big usability hit.

Indeed, enums and other dotted constants are the heart of the matter.
And I get your point about not making useful refactoring more difficult.
Still it could make sense (in the philosophy of PEP 642, again) to defer
the choice and see how strong the need is. What PEP 642 ends up
proposing will be Nick Coghlan's call.

Cheers,
Baptiste

P.S.: a few examples for "taste":

# your example
match status:
  case == HTTPStatus.NOT_FOUND:
...

vs. case HTTPStatus.NOT_FOUND:

# worst-case where constants are buried in the pattern
match sock:
  case socket(family=(==socket.AF_INET), type=(==socket.SOCK_STREAM)):
...

vs. case socket(family=socket.AF_INET, type=socket.SOCK_STREAM):

# same with plain constants, PEP 642 only
match sock:
  case socket(family=(==AF_INET), type=(==SOCK_STREAM)):
...
___
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/CZWZRN5J6QIJZM2C4IUOBGCWNJ7EM6QX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Baptiste Carvello]

Hi,

Le 08/11/2020 à 07:47, Nick Coghlan a écrit :
> Hi folks,
> 
> I have updated PEP 642 significantly based on the feedback received
> over the past week.
> 
> [...]
a change that I feel is insufficiently discussed is the choice to have
"attr_constraint" as an inferred constraint. I can think of arguments to
defer it for now at least:

* it is a one way door (if dotted names are made a constraint pattern
now, they can't become a capture pattern later);

* it makes a difference from assignment target syntax, where you can
assign to a dotted name;

* the shorthand notation is less valuable than for literals, as dotted
names are verbose already, 3 more characters make little difference;

* the user has no explicit syntax to override the inferred semantics.

I feel like some discussion of this choice in the PEP would make sense.

Cheers,
Baptiste
___
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/RQPUV7PABLBNYJ7FI7QYCS6TKJ4H2Q2A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)

[Baptiste Carvello]

Le 14/08/2020 à 16:24, Mark Shannon a écrit :
> 
> https://github.com/markshannon/pep622-critique

Hi all,

reading through this made me think of 3 ideas which I think are new [1].
2 of them are about the Value Pattern question, the last one is a small
nit about the Django example.

* the critique points the limitations to the use of pattern matching in
__init__ methods, because Capture Patterns can't assign to dotted names.

Thus the currently proposed dot-based rule is a limitation not just for
Value Patterns, as already heavily discussed, but also for Capture
Patterns. Moreover, this limitation cannot be lifted after the fact if
the __init__ method use-case proves important in the future.

* the critique points that Value Patterns with booleans would need
identity-, not equality-based comparison. This leads to the idea that,
if a special syntax if eventually used for Value Patterns, using the
comparison operator in it might be useful. Thus we could have:

>>> match int_or_boolean:  # ok, dubious design!
... case is True:  # same as "if int_or_boolean is True:"
... print("boolean true")
... case is False:
... print("boolean false")
... case == ONE:  # same as "if int_or_boolean == ONE:"
... print("integer 1")

* the Django example could be written more idiomatically by relying more
on destructuring instead of having a guard:

>>> match value:
... case [first, *_, label := (Promise() | str())]:
... value = value[:-1]
... case _:
... label = key.replace('_', ' ').title()

Cheers,
Baptiste

[1] as in: I skimmed through most of the threads and believe they have
not already been said (famous last words…)
___
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/P7BNZEOOKAEVZCSOVAN7WZYYHLZYO4QR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 constant value syntax idea

[Baptiste Carvello]

Hello,

Le 15/07/2020 à 13:37, Mohammad Foroughi via Python-Dev a écrit :
> Hi, I had an idea regarding the pattern matching issue of comparing with
> a previous constant variable instead of assigning to a new local
> variable. I'm not sure if this has been brought up before but instead of
> using a symbol with the case statement what if we used a keyword.
> 
> [...]
> 
> Other ideas for the keyword are "const" or "static" but these 2 are more
> difficult to recognise since they aren't in other parts of python but
> the "global" keyword is already implemented so it would be easy to
> understand.

What about simply "is", which is already a keyword?

AFAIK "is" has no meaning as a prefix operator as of now, so hopefully
it would not make the grammar ambiguous (how can one check that for sure?).

match color:
case is RED:
print("red")
case is BLUE:
print("blue")
case other:
print(f"unknown color {other}")

or with Rhodri James' example:

match value:
case is x:
print("value matches")
case Point(is x, y):
print("value matches x, y captured")
case Line(Point(is x1, y1), Point(x2, is y2)):
print("wouldn't call that pretty, but not ugly either")


Cheers,
Baptiste

P.S.: granted, it could mislead some users into thinking that the
comparison is done with "is" instead of "=="; but then, patterns are
special in many ways, users will have to just learn them…
___
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/TZEJHFALXL4OUBDYNQ5D6PEALUYHG57I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Cython and incompatible C API changes

[Baptiste Carvello]

Hi,

Le 22/06/2020 à 11:21, Stefan Behnel a écrit :
> [...]
> 
> Basically, for maintained packages, I consider shipping the generated C
> code the right way. Less hassle, easier debugging, better user experience.
> For unmaintained packages, regenerating the C code at build time *can*
> extend the lifetime of the package to newer environments for as long as it
> does not run into failures due to Cython compiler changes (so you trade one
> compatibility level for another one).
> 
> The question is whether the point at which a package becomes unmaintained
> can ever be clear enough to make the switch. Regardless of which way you
> choose, at some point in the future someone will have to do something,
> either to your code or to your build setup, in order to prevent fatal bitrot.

This makes me wonder: could there be a (non-default, use at your own
risk) pip option to rerun Cython before compile? This would allow users
to try and workaround compilation failures on their side.

Not that the unpack/run Cython/bdist_wheel dance is really difficult,
but users have to find out/remember how to do it.

Cheers,
Baptiste
___
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/6GTTUMLAT3MMMOTNHLQFRH2C2PZBFWOB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

[Baptiste Carvello]

Le 28/06/2019 à 18:56, Mariatta a écrit :
> Hi,
> 
> I've updated PEP 581 yesterday, adding the "Downsides of GitHub" section.
> 
> https://www.python.org/dev/peps/pep-0581/#downsides-of-github

Hi,

another missing point: the necessity to register an account with a third
party's social network, and accept their terms of service. For this
matter, a GH account is different from a BPO account because it is not
controlled by the PSF, and must be unique across projects. While I
understand this privacy concern is not shared by most core devs, it
should still be acknowledged.

Cheers,
Baptiste
___
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/CQGNNFT7HQXC7YJ5ASKAOZYVXZ32DYEX/

Re: [Python-Dev] Python in next Windows 10 update

[Baptiste Carvello]

Hello,

Le 21/05/2019 à 22:30, Steve Dower a écrit :
>
> [...]
> 
> * the Python 3.7 installed from the store will not auto-update to 3.8,
> but when 3.8 is released we (Microsoft) will update the redirect to
> point at it
> * if you pass arguments to the redirect command, it just exits with an
> error code - you only get the Store page if you run it without arguments

I was wondering how those 2 bullet points combine. Say a user installs
3.7 from the store, then uses "python.exe" with arguments, in a shebang
line or a batch script.

Does it mean the script might break unexpectedly when 3.8 is released?
Then, would it make sense for the redirect command to proxy to the 3.7
install when arguments are passed?

Cheers,
Baptiste


___
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Baptiste Carvello]

Le 28/06/2018 à 01:31, Greg Ewing a écrit :
> Well, I remain profoundly unconvinced that writing comprehensions
> with side effects is ever a good idea, and Tim's examples did
> nothing to change that.

Comprehensions with side effects feel scary indeed. But I could see
myself using some variant of the "cumsum" example (for scientific work
at the command prompt):

>>> x=0; [x:=x+i for i in range(5)]

Here the side effects are irrelevant, the "x" variable won't be reused.
But it needs to be initialized at the start of the comprehension.

I would happily get rid of the side-effects, but then what would be a
non-cryptic alternative to the above example?

Baptiste
___
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Baptiste Carvello]

Not giving a vote, as I'm just a lurker, but:

Le 25/06/2018 à 01:30, Greg Ewing a écrit :
> 
> Actually, I'm closer to -1 on (a) as well. I don't like := as a
> way of getting assignment in an expression. The only thing I would
> give a non-negative rating is some form of "where" or "given".

This resonates with me for a yet different reason: expressing the
feature with a new operator makes it feel very important and
fundamental, so that beginners would feel compelled to learn it early,
and old-timers tend to have a strong gut reaction to it. Using merely a
keyword makes it less prominent.

Baptiste
___
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] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

[Baptiste Carvello]

Hello,

since this thread is restarting in debriefing mode: one thing struck me
as a non-committer following python-dev.

It seems that we (non-committers) have a difficulty making the
distinction between pre-implementation design discussions (PEPs beeing
the typical example), where relevant technical comments are welcome,
even on minor points, and post-commit discussions, where the maintainer
already made the design decisions, and discussing anything except real
bugs is unhelpful.

In this particular thread, the distinction was all the more blurred by
the very generic title. A thread titled something like Commit-xxx:
should mock try to detect user typos? would have been much less likely
to attract comments discussing principles in the abstract, without
taking the context into account.

Regards,

Baptiste

___
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] Python3 complexity

[Baptiste Carvello]

Le 10/01/2014 16:35, Nick Coghlan a écrit :

 One idea we're considering for Python 3.5 is to have a report of
 ascii on a POSIX OS imply the surrogateescape error handler (at
 least for the standard streams, and perhaps in other contexts), since
 the OS reporting the POSIX/C locale almost certainly indicates a
 configuration error rather than intentional behaviour.

would it make sense to be more general, and allow a lenient mode,
where all files implicitly opened with the default encoding would also
use the surrogateescape error handler ?

That way, applications designed to process text mostly written in the
default encoding would just call sys.set_lenient_mode() and be done.

Of course, libraries would need to be strongly discouraged to ever use
this and encouraged to explicitly set the error handler on appropriate
files instead.

Cheers,

Baptiste

___
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] cpython: Rename contextlib.ignored() to contextlib.ignore().

[Baptiste Carvello]

Le 15/10/2013 05:12, Glenn Linderman a écrit :
 
 I've got an extra can of break_out_if paint here...
 

another shed color:

with contextlib.except_pass(FileNotFoundError):
os.unlink(fname)

explicit and hopefully not too ugly

___
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] Introducing Electronic Contributor Agreements

[Baptiste Carvello]

Le 05/03/2013 04:13, Stephen J. Turnbull a écrit :
 Mark Lawrence writes:
 
   People already use the bug tracker as an excuse not to contribute, 
   wouldn't this requirement make the situation worse?
 
 A failure to sign the CLA is already a decision not to contribute to
 the distribution

my 2 cents as an occasional contributor of minor patches: I understand
that the scarce resource is reviewer time, so I would definitely accept
to sign the CLA with my next contribution before a reviewer invests his
time in it.

However, please don't make the popup too pushy. I abhor websites which
push people into entering legally binding agreements with one click
without the opportunity to study them carefully (personnally, this would
not be a problem as I already know what the CLA is about, but other
contributors might not).

Also, please keep the possibility to use the old paper-based signing
procedure. I for one don't consider so-called electronic signatures
based on email address verification (as opposed to real crypto) to be as
good as a handwritten signature, and I don't want to legitimize them by
using them.

Cheers,
Baptiste

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

Re: [Python-Dev] Backporting PEP 414

[Baptiste Carvello]

Le 29/02/2012 00:25, Nick Coghlan a écrit :

 Also, I think there may be some confusion about Armin's plan to handle
 3.2 - he aims to write an *import hook* that accepts the u/U prefixes
 during tokenisation, not a source-to-source transform like 2to3. 
 

this needs to be emphasized. Read from the outside, the whole PEP 414
discussion could give the idea that 3.2 is a second class citizen for
porting, like 3.0 and 3.1 have been. If such an opinion would spread,
that would be bad PR for Python 3 as a whole.

Baptiste

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

Re: [Python-Dev] Fixing the XML batteries

[Baptiste Carvello]

Le 16/12/2011 07:53, Stefan Behnel a écrit :

 Additionally, the documentation on the xml.sax page would benefit from
 the following paragraph:
 
 
 [[Note: The xml.sax package provides an implementation of the SAX
 interface whose API is similar to that in other programming languages.
 Users who are unfamiliar with the SAX interface or who would like to
 write less code for efficient stream processing of XML files should
 consider using the iterparse() function in the xml.etree.ElementTree
 module instead.]]
 
 

A small caveat to note about iterparse(), which I otherwise like a lot:
when processing very big data (I encountered this with a region-wide
openstreetmap XML dump), you have to remove the processed nodes from the
root element. Otherwise, its memory footprint increases with the size of
the document.

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

Re: [Python-Dev] open(): set the default encoding to 'utf-8' in Python 3.3?

[Baptiste Carvello]

Le 28/06/2011 16:46, Paul Moore a écrit :


-1. This will make things harder for simple scripts which are not
intended to be cross-platform.


+1 to all you said.

I frequently use the python command prompt or python -c for various quick 
tasks (mostly on linux). I would hate to replace my ugly, but working


 open('example.txt').read()

with the unnecessarily verbose

 open('example.txt',encoding='utf-8').read()

When using python that way as a swiss army knife, typing does matter.


My preferred solution would be:


- emit a warning if the encoding argument is not set


By the way, I just thought that for real programming, I would love to have a 
-Wcrossplatform command switch, which would warn for all unportable constructs 
in one go. That way, I don't have to remember which parts of 'os' wrap 
posix-only functionnality.


Baptiste

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

Re: [Python-Dev] Generating patch files

[Baptiste Carvello]

Le 16/03/2011 18:49, Martin v. Löwis a écrit :


Having the revision of cpython to compare against is the
difficult part;


how about: 'max( ancestors(default) and not outgoing() )' ?

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

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

[Baptiste Carvello]

Stephen J. Turnbull a écrit :

What really saves the day here is not that common encodings just
don't do that.  It's that even in the case where only syntactically
significant bytes in the representation are URL-encoded, they *are*
URL-encoded.  As long as the parsing library restricts itself to
treating only wire-format input, you're OK.[1]  But once you start
doing things that involve decoding URL-encoding, you can run into
trouble.

If I understand you well, any processing of unquoted bytes is dangerous per se. 
If this is true, then perhaps 'unquote' doesn't disserve the criticism it 
received in this thread for always returning str. This would be in fact quite 
fortunate, as it forces url processing to either happen on quoted bytes (before 
calling 'unqote'), or on unquoted str (on the result of 'unquote'), both of 
which are safe.


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

Re: [Python-Dev] Polymorphic best practices [was: (Not) delaying the 3.2 release]

[Baptiste Carvello]

R. David Murray a écrit :

I'm trying one approach in email6:
Bytes and String subclasses, where the subclasses have an attribute
named 'literals' derived from a utility module that does this:

literals = dict(
empty = '',
colon = ':',
newline = '\n',
space = ' ',
tab = '\t',
fws = ' \t',
headersep = ': ',
)

class _string_literals:
pass
class _bytes_literals:
pass

for name, value in literals.items():
setattr(_string_literals, name, value)
setattr(_bytes_literals, name, bytes(value, 'ASCII'))
del literals, name, value

And the subclasses do:

class BytesHeader(BaseHeader):
lit = email.utils._bytes_literals

class StringHeader(BaseHeader):
lit = email.utils._string_literals



I've just written a decorator which applies a similar strategy for insulated 
functions, by passing them an appropriate namespace as an argument. It could be 
useful in cases where only a few functions are polymorphic, not a full class or 
module.


http://code.activestate.com/recipes/577393-decorator-for-writing-polymorphic-functions/

Cheers, B.

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

Re: [Python-Dev] bytes / unicode

[Baptiste Carvello]

P.J. Eby a écrit :

[...] stdlib constants are almost always ASCII, 
and the main use cases for ebytes would involve ascii-extended encodings.)


Then, how about a new ascii string literal? This would produce a special kind 
of string that would coerce to a normal string when mixed with a str, and to a 
bytes using ascii codec when mixed with a bytes. Then you could write


 a/.join(base, path)

and not worry if base and path are both str, or both bytes (mixed being of 
course forbidden).


B.

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

Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs

[Baptiste Carvello]

Victor Stinner a écrit :


I suppose that each codec will have a different list of accepted input and 
output types. Example:


   bz2: encode:bytes-bytes, decode:bytes-bytes
   rot13: encode:str-str, decode:str-str
   hex: encode:bytes-str, decode: str-bytes 


A user point of view: please NO.

This might be more consistent with the semantics, but it forces users to scratch 
their head each time to find out which types are involved. I'd rather all 
methods take and return the same types, independant of codec, that is:


.encode : str-bytes
.decode : bytes-str
.(un)transform : same type, str-str or bytes-bytes

All other uses can be trivially done with .encode('ascii')/.decode('ascii'). 
Changing the type of *ascii* text is easy, understanding bytes vs str semantics 
is not!


Cheers,
B.

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

Re: [Python-Dev] __file__

[Baptiste Carvello]

Antoine Pitrou a écrit :

Le Sun, 28 Feb 2010 21:45:56 +0100, Baptiste Carvello a écrit :

bytecode-only in a zip is used by py2exe, cx_freeze and the like, for
space reasons. Disabling it would probably hurt them.


Source code compresses quite well. I'm not sure it would make much of a 
difference. 


I did a quick check on the stdlib: a zip with .py and .pyc is about 80% bigger 
than one with .pyc only. If you use only the bytecode, this can be seen as 
waisted space. On the other hand, if you ever need to debug the application, 
source is very handy...


Anyway, I'm a bit worried if bytecode-only is disabled from zipimport without 
some input from the developpers of py2exe/cx_freeze/etc, as they are big users 
of it.


Cheers, Baptiste

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

Re: [Python-Dev] __file__

[Baptiste Carvello]

Nick Coghlan a écrit :


Another option is to remove bytecode-only support from the default
filesystem importer, but keep it for zipimport (since the stat call
savings don't apply in the latter case).



bytecode-only in a zip is used by py2exe, cx_freeze and the like, for space 
reasons. Disabling it would probably hurt them.


However, making a difference between zipimport and the filesystem importer means 
the application will stop working if I unzip the library zip file, which is 
surprising. Unzipping the zip file can be handy when debugging a bug caused by a 
forgotten module.


Cheers,
Baptiste

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

Re: [Python-Dev] __file__

[Baptiste Carvello]

Brett Cannon a écrit :


However, making a difference between zipimport and the filesystem
importer means the application will stop working if I unzip the
library zip file, which is surprising. Unzipping the zip file can be
handy when debugging a bug caused by a forgotten module.


Is it really that hard to unzip a bunch of .pyc files, modify what you 
need to, and then zip it back up? And if you are given a zip file of 
only .pyc files you can't really debug anything anyway.




Well, this is a micro-use-case, I admit, I only mention it because it's 
something I've really done. It's only useful for debugging the building process, 
not the application (so I do have the source at hand), and the only reason for 
not rezipping is to test more quickly. I can definitely live without it!


Cheers, Baptiste

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

Re: [Python-Dev] PyPI comments and ratings, *really*?

[Baptiste Carvello]

Robert Kern a écrit :

While I do have a couple of packages on PyPI, I use PyPI as a consumer 
of packages much more frequently, every day in fact. 


Another consumer opinion: when investigating a new package, I usually look for 
the following things, in that order:


1) the big picture description: is there a coherent design? does it fit my 
needs? On PyPI, the description field should provide that.


2) the changelog: is the project still alive? are bugs fixed, or just features 
added? is the code rewritten from scratch for each release? Well, every project 
on PyPI should have a public changelog, so a link to that fits my need.


3) documentation: I don't necessarily care for the number of lines, but more 
whether it is understandable and goes into sufficient detail to not leave me 
guessing. Again, a link to the docs fits my needs. A single number (number of 
documentation lines,...) does not.


4) a mailing list archive (or newsgroup, or web forum), where I'm looking for 
signs of a healthy community. I usually go for the -devel list, but a -user list 
will do as well if the committers keep an eye on it.


If a healthy community exists around a project, I will completely disregard 
comments, if present: time invested in the community speaks louder than the 
opinion of random bystanders. Only for small projects with no real community 
will I look at the comments (+ answers from the author) in order to make an 
opinion on the developpement process. I always disregard ratings.


So as a conclusion about comments, they can have their use for projects without 
a publicly archived mailing list, but can otherwise be *replaced* by a direct 
link to a list archive. This could be a reasonable default for PyPI: disable 
comments when a link to a list archive is provided.


While my experience may not be that of a typical user, I believe users will 
ultimately make use of all information they are provided. So it is important to 
provide the most relevant information, and not just what naive users ask for.


Cheers,
B.

___
Python-Dev mailing list
Python-Dev@python.org
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 383: Non-decodable Bytes in System Character Interfaces

[Baptiste Carvello]

Glenn Linderman a écrit :


3. When an undecodable byte 0xPQ is found, decode to the escape 
codepoint, followed by codepoint U+01PQ, where P and Q are hex digits.




The problem with this strategy is: paths are often sliced, so your 2 codepoints 
could get separated. The good thing with the PEP's strategy is that 1 character 
stays 1 character.


Baptiste

___
Python-Dev mailing list
Python-Dev@python.org
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 383: Non-decodable Bytes in System Character Interfaces

[Baptiste Carvello]

Lino Mastrodomenico a écrit :


Only for the new utf-8b encoding (if Martin agrees), while the
existing utf-8 is fine as is (or at least waaay outside the scope of
this PEP).



This is questionable. This would have the consequence that \udcxx in a python 
string would sometimes mean a surrogate, and sometimes mean raw bytes, depending 
on the history of the string.


By contrast, if the new utf-8b codec would *supercede* the old one, \udcxx would 
always mean raw bytes (at least on UCS-4 builds, where surrogates are unused). 
Thus ambiguity could be avoided.


Baptiste

___
Python-Dev mailing list
Python-Dev@python.org
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 383: Non-decodable Bytes in System Character Interfaces

[Baptiste Carvello]

Glenn Linderman a écrit :



If there is going to be a required transformation from de novo strings 
to funny-encoded strings, then why not make one that people can actually 
see and compare and decode from the displayable form, by using 
displayable characters instead of lone surrogates?




The problem with your escape character scheme is that the meaning is lost with 
slicing of the strings, which is a very common operation.




I though half-surrogates were illegal in well formed Unicode. I confess
to being weak in this area. By legitimate above I meant things like
half-surrogates which, like quarks, should not occur alone?
  


Illegal just means violating the accepted rules.  In this case, the 
accepted rules are those enforced by the file system (at the bytes or 
str API levels), and by Python (for the str manipulations).  None of 
those rules outlaw lone surrogates.  [...]




Python could as well *specify* that lone surrogates are illegal, as their 
meaning is undefined by Unicode. If this rule is respected language-wise, there 
is no ambiguity. It might be unrealistic on windows, though.


This rule could even be specified only for strings that represent filesystem 
paths. Sure, they are the same type as other strings, but the programmer usually 
knows if a given string is intended to be a path or not.


Baptiste

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

Re: [Python-Dev] setuptools has divided the Python community

[Baptiste Carvello]

Tennessee Leeuwenburg a écrit :
I would suggest there may be three use cases for Python installation 
tools. Bonus -- I'm not a web developer! :)


Case One: Developer wishing to install additional functionality into the 
system Python interpreter forever
Case Two: Developer wishing to install additional functionality into the 
system Python interpreter for a specific task
Case Three: Person wanting to install an application which happens to be 
written in Python




a maybe more exotic Case Four: the enlightened open-source user, who wants to 
install an application, but might like to look under the hood, either to tweek 
it to his needs, or to investigate a bug.


In that case, each application comming with a private version of various system 
libraries is unwelcomed complication, so that using the platform's package 
manager is a much better solution.


Cheers,
B.

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

Re: [Python-Dev] setuptools has divided the Python community

[Baptiste Carvello]

Tres Seaver a écrit :


Note that the kind of applications I work on tend to be the sort which
will run as server apps, and which will (in production) be the entire
rasion d'etre for the machine they run on, which makes the cost of
isolation tiny compared to the consequences of failed isolation.



Indeed. More fundamentally, different use cases call for the dependency 
management to happen in different places.


In the case of the web application, the dependencies must be resolved on the 
developper machine, and tested there, then the full bundle is pushed to the 
production server where failure is not an option.


This is in strong contrast with the Debian (for example) use case, where you 
want the dependencies to be resolved on the end user machine, because that way 
Debian has to support just N independant packages, not NxN possible user 
configurations.


Cheers,
B.

___
Python-Dev mailing list
Python-Dev@python.org
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 377 - allow __enter__() methods to skip the statement body

[Baptiste Carvello]

Nick Coghlan a écrit :


Implementing __with__ instead would give the CM complete control over
whether or not to execute the block.

please note, however, that this is an important change in the semantics of the 
with statement. As things are today, barring exceptional circunstances, the body 
of the with statement *will* be executed immediately. This allows to forget 
about the with statement when first reading code, as it doesn't change the 
intent of the programmer. What Glyph is proposing is more akin to Ruby code blocks.


cheers,
Baptiste

___
Python-Dev mailing list
Python-Dev@python.org
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 30XZ: Simplified Parsing

[Baptiste Carvello]

Steven Bethard a écrit :
 On 5/2/07, Michael Foord [EMAIL PROTECTED] wrote:
 Implicit string concatenation is massively useful for creating long
 strings in a readable way though:

 call_something(first part\n
second line\n
 third line\n)

 I find it an elegant way of building strings and would be sad to see it
 go. Adding trailing '+' signs is ugly.
 
 You'll still have textwrap.dedent::
 
 call_something(dedent('''\
 first part
 second line
 third line
 '''))
 
 And using textwrap.dedent, you don't have to remember to add the \n at
 the end of every line.
 
 STeVe

maybe we could have a dedent literal that would remove the first newline and
all indentation so that you can just write:

call_something( d'''
 first part
 second line
 third line
 ''' )

Cheers
Baptiste

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

Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

[Baptiste Carvello]

 Ah, threads :-( It turns out that you need to invoke GetMessage in the
 context of the thread in which the window was created. In a different
 thread, you won't get any messages.
 
 I'd be interested to hear about other situations where threading would 
 cause a problem.  My suspicion is that Windows is the hard one, and as 
 I've shown that one is solvable.
 
 
I've tried something similar on Linux, with gtk an wx.

You can run the gtk main loop in its own thread, but because gtk is not thread
safe, you have to grab a mutex everytime you run gtk code outside the thread the
mainloop is running in. So you have to surround your calls to the gtk api with
calls to gtk.threads_enter and gtk.threads_leave. Except for callbacks of
course, because they are executed in the main thread... Doable, but not fun.

The same goes for wx. Then all hell breaks loose when you try to use both gtk
and wx at the same time. That's because on Linux, the wx main loop calls the gtk
mainloop behind the scenes. As far as I know, that problem can not be solved
from python.

So yes that strategy can work, but it's no silver bullet.

Cheers,
Baptiste

___
Python-Dev mailing list
Python-Dev@python.org
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 and the Linux Standard Base (LSB)

[Baptiste Carvello]

Armin Rigo a écrit :

 Now I only have to hope that 2.4.4 makes its way out of 'unstable' soon.
 As far as I can tell sysadmins installing the current 'testing' would
 still be getting a Python 2.4.3, not modern enough to cope with the
 arithmetic overflow issues introduced by the cutting-edge GCC of
 'testing'.

well, the usual way to express your hope would be to file a bug on the 
python2.4 package, to make sure the maintainers are aware of the problem. 
However, it looks like 2.4.4 made it to testing today, so it might not be 
necessary.

Cheers,
BC

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

Re: [Python-Dev] Why are contexts also managers? (wasr45544 -peps/trunk/pep-0343.txt)

[Baptiste Carvello]

Terry Reedy a écrit :
 So I propose that the context maker be called just that: 'context maker'. 
 That should pretty clearly not be the context that manages the block 
 execution.
 
+1 for context maker. In fact, after reading the begining of the thread, I came 
  up with the very same idea.

 Similar, a context_maker function could be named any of 'context_maker', 
 'context_manager', or 'context', with the latter two referring to the 
 return value.  In the context of 'with  as name:', either of the latter 
 two reads better to me.
 
 I would call the decorator @contextmaker since that is what it turns the 
 decorated function into.
 
I'm confused here. Do we agree that the object with __enter__ and __exit__ is a 
context manager, and the object with just __context__ is a context maker ?
If so , I would say the decorator still produces a context manager.

Baptiste

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

Re: [Python-Dev] setuptools in 2.5.

[Baptiste Carvello]

Hello,

just one more datapoint to help Phillip change his mind on the default install 
behavior and the monkeypatching: this is actually hurting adoption of 
setuptools.

example: the matplotlib folks wanted to add *optional* setuptool support, but 
this is impossible because simply importing setuptools has too much 
side-effects. So instead, they ask the setuptool users to use
python -c import setuptools; execfile('setup.py') install
That's just too bad, and much more confusing than setup.py install_egg !

Oh, and don't get me wrong, I *love* eggs. They are great for many use cases, 
even for a Debian user!
 From the user point of view, they definitely belong in the stdlib, the 
sooner, the better. They just need a little bit more polishing.

Phillip, thank you a lot for making this happen :-) I feel that the hostility 
is 
undeserved.

Baptiste

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

Re: [Python-Dev] Py3k: Except clause syntax

[Baptiste Carvello]

Greg Ewing a écrit :

except type as value:
 

what about

 except type with value:

a program dies with an error message, not as an error message.

ciao,
BC

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

Re: [Python-Dev] bytes thoughts

[Baptiste Carvello]

Josiah Carlson a écrit :

 They aren't considered because they are *obvious* to most (if not all)
 sane people who use Python.  

They are not *that* obvious. Logical operations on ints have allowed users to 
forget about size (and shoot themselves in the foot from time to time). Or is
1^(~1) == -1 obvious ? Well, maybe that's not sane either :-)

 Think of future bytes behavior to be
 similar to current array behavior, with a few bits and pieces added to
 make life easier (like all of the current string methods, etc.)
 

I didn't get before that the array behavior really *defined* the bytes 
behavior. 
OK, I'll keep that in mind.

Cheers,
BC

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

Re: [Python-Dev] iterator API in Py3.0

[Baptiste Carvello]

Phillip J. Eby a écrit :

 I didn't misstate her argument or reduce it to the absurd.  I simply 
 applied that argument consistently to similar features of Python.  It's you 
 who is concluding that this results in absurdity; I made no such 
 conclusion.  I'm simply pointing out that in 3.0 we should be 
 consistent.  Either we should have ob.iter() and ob.len(), or else we 
 should have a builtin next().
 

There is a difference though: a next() builtin would change the state of its 
argument, what len() ant iter() don't do. I usually prefer methods to functions 
for operations that modify an object.
But then we have setattr and delattr :)

I'd say it makes sense to go for practicallity here. Let's keep the next() 
method as it is, and document this as an exception. The canonical place could 
be 
section 3.3 in the language reference, but for some reason, it does not list 
next() right now...

Cheers,
BC

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

Re: [Python-Dev] bytes thoughts

[Baptiste Carvello]

Greg Ewing a écrit :
 Why not just support bitwise operations directly
 on the bytes object?
 

Sure, what counts is that all the nice features that Python has for editing 
binary data are usable with the bytes object.
These include bitwise operations, hex() and oct() representation functions and 
litterals, the struct module (as Paul Svensson kindly reminded me). Do I forget 
something ?

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

Re: [Python-Dev] bytes thoughts

[Baptiste Carvello]

some more thoughts about the bytes object:

1) it would be nice to have an trivial way to change a bytes object to an int / 
long, and vice versa.

Rationale:

while manipulating binary data will happen mostly with bytes objects, some 
operations are better done with ints, like the bit manipulations with the |~^ 
operators. So we should make sure there is no impedance mismatch between those 
2 
ways of editing binary data. Getting an individual byte at a time is not 
sufficient, because the part of the data you want to edit might span over a few 
bytes, or simply fall across a byte boundary.

Toy implementation:

  class bytes(list):
... def from_int(cls, value, length):
... return cls([(value  8*i) % 256 for i in range(length)[::-1]])
... from_int=classmethod(from_int)
... def int(self):
... return sum([256**i*n for i,n in enumerate(self[::-1])])
...
 

The length argument to from_int is necessary to create a fixed number of bytes, 
event if those bytes are 0.

Use case:

let's say you have a binary record made of 7 bits of padding and 3x3 bytes of 
unix permissions. You want to change the user permissions, and store the record 
back to a bytes object:

  record=bytes([1,36]) # this could be a slice of a preexisting bytes object
  perms=record.int()
  print oct(perms)
0444
  perms =~( 7 6 )   # clear the bits corresponding to user permissions
  perms |=   6 6 # set the bits to the new value
  print oct(perms)
0644
  record=bytes.from_int(perms,2)
 

2) a common case of interactive use is to display a bytes string as a character 
string in order to spot which parts are text. In this case you ignore non-ASCII 
characters, and replace everything that cannot be printed with a space (as some 
hex editors do). So you don't need to care about encodings.

  import string
  def printable(c):
... if not c in string.printable: return ' '
... if c.isspace(): return ' '
... return c
...
  class bytes(list):
... def printable_ascii(self):
... return u.join([printable(chr(i)) for i in nb])
...
  nb=bytes([48,0,10,12,34,65,66])
  print nb.printable_ascii()
0   AB
 

by the way, what will chr return in py3k ?

Cheers,
BC

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