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

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

[Python-Dev] Re: Switching to Discourse

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

[Python-Dev] Re: Switching to Discourse

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

[Python-Dev] Re: Switching to Discourse

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

[Python-Dev] Re: Switching to Discourse

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

[Python-Dev] Re: Switching to Discourse

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

[Python-Dev] Re: Switching to Discourse

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

[Python-Dev] Re: Switching to Discourse

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

[Python-Dev] Re: Switching to Discourse

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

[Python-Dev] Re: Moving to Discourse

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

[Python-Dev] Re: Moving to Discourse

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

[Python-Dev] Re: Moving to Discourse

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

[Python-Dev] Re: Switching to Discourse

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. > >

[Python-Dev] Re: Switching to Discourse

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

[Python-Dev] Re: Switching to Discourse

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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()

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

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 Car

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

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

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

ub 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

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

mple, 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

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

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 >

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

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

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

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

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

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

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

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

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

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 Carve

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

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

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

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?

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

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

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

ust 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 T

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

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, >

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

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

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

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,

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

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

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

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

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

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

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

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

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

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,

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

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 >

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

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

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

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".

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)

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

Re: [Python-Dev] Python3 complexity

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

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

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 ___

Re: [Python-Dev] Introducing Electronic Contributor Agreements

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

Re: [Python-Dev] Backporting PEP 414

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

Re: [Python-Dev] Fixing the XML batteries

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

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

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,

Re: [Python-Dev] Generating patch files

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

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

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

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

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 = '

Re: [Python-Dev] bytes / unicode

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,

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

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.

Re: [Python-Dev] __file__

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

Re: [Python-Dev] __file__

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.

Re: [Python-Dev] __file__

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.

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

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

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

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

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

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,

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

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

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

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

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

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.

Re: [Python-Dev] PEP 377 - allow __enter__() methods to skip the statement body

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

Re: [Python-Dev] PEP 30XZ: Simplified Parsing

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)

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

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

Re: [Python-Dev] Python and the Linux Standard Base (LSB)

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

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

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.

Re: [Python-Dev] setuptools in 2.5.

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

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

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

Re: [Python-Dev] bytes thoughts

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) ==

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

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

Re: [Python-Dev] bytes thoughts

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

Re: [Python-Dev] bytes thoughts

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