I have written an xsd parser to generate python classes. I also have
written a utility to read in an xml file to populate the python classes.
As well as a utility to write xml from the python classes thus generated.
For example the code below that I include here shows a small sample of the
On Tue, Jan 18, 2022 at 6:24 AM Victor Stinner wrote:
> Hi,
>
> My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on
> updating Python 3.10 to Python 3.11 in Fedora, but some specific
> Python 3.11 incompatible changes are causing more troubles than
> others:
>
On Tue, Jan 18, 2022 at 10:58 PM Christopher Barker
wrote:
> On Tue, Jan 18, 2022 at 10:30 AM Brett Cannon wrote:
>
>> I remember that "noisy by default" deprecation warnings were widely
>>> despised.
>>>
>>> One thought, what if they were off by default UNLESS you were doing unit
>>> tests?
On Tue, Jan 18, 2022 at 10:30 AM Brett Cannon wrote:
> I remember that "noisy by default" deprecation warnings were widely
>> despised.
>>
>> One thought, what if they were off by default UNLESS you were doing unit
>> tests?
>>
>
> I believe pytest already does this.
>
Indeed it does, at least
Guido van Rossum wrote:
> I personally think F-strings should not be usable as docstrings. If you
> want a dynamically calculated docstring you should assign it dynamically,
> not smuggle it in using a string-like expression. We don't allow "blah {x}
> blah".format(x=1) as a docstring either, not
Steven D'Aprano wrote:
> On Sat, Jan 08, 2022 at 12:59:38AM +0100, jack.jan...@cwi.nl wrote:
> For example, the arrow syntax for Callable `(int) -> str` (if accepted)
> could be a plain old Python expression, usable anywhere the plain old
> Python expression `Callable[[int], str]` would be.
In
On 2022-01-18 21:58, Pablo Galindo Salgado wrote:
The code that computes the lines is already quite complex (to the point
that has to do some AST analysis and post-parsing) so I am quite worried
to introduce a lot of complexity in this area. I am fine doing something
that we can easily check
On 1/18/2022 2:35 PM, Jim J. Jewett wrote:
The problem is that
[*s3, *s4] = (a, b, 1, 2, 3)
is ambiguous ...
It wouldn't have to be... but as you say, it needs to be explicit.
*s3 could get all the content, and *s4 a tuple with no members.
___
I'm seeing enough different interpretations to think things aren't quite
specified -- but I'm not sure if it matters.
(1) Is any of this something that should affect computation, or is it really
just a question of how to interpret possibly ambiguous documentation?
(2) Are any of these
The code that computes the lines is already quite complex (to the point
that has to do some AST analysis and post-parsing) so I am quite worried to
introduce a lot of complexity in this area. I am fine doing something that
we can easily check for (spawns all the line) but I would be against having
On Tue, Jan 18, 2022 at 5:48 PM Steve Dower wrote:
> Discovering during alpha that some packages haven't updated for the
> release that hasn't happened yet isn't the end of the world. Reverting
> the changes now is probably a bit premature - realistically we can undo
> these anytime during beta
On 18/01/2022 20:41, Pablo Galindo Salgado wrote:
We cannot base the computation on a % because is possible that the
location markers are relevant
but the variables, function names or constructs are just very large. I
think that the idea of "spawns
the whole line" is sensible, though.
On Tue,
tox and pytest look at PY_COLORS:
https://github.com/tox-dev/tox/blob/9cc692d85c9ce84344ea7fee4b127755c6099a32/src/tox/session/commands/help.py
https://docs.pytest.org/en/6.2.x/reference.html#envvar-PY_COLORS
On Tue, 18 Jan 2022 at 21:17, Ethan Furman wrote:
> On 1/18/22 11:59 AM, Pablo
On 1/18/22 11:59 AM, Pablo Galindo Salgado wrote:
> We considered using colours and other markers such as bold text, but that
opens a considerable can of worms with
> detecting in all systems and configurations if that can be done. I have been
told that some of these situations are
> quite
We cannot base the computation on a % because is possible that the location
markers are relevant
but the variables, function names or constructs are just very large. I
think that the idea of "spawns
the whole line" is sensible, though.
On Tue, 18 Jan 2022 at 20:32, Steve Dower wrote:
> On
On 1/18/2022 7:59 PM, Pablo Galindo Salgado wrote:
We considered using colours and other markers such as bold text, but
that opens a considerable can of worms with detecting in all systems and
configurations if that can be done. I have been told that some of these
situations are quite tricky
We considered using colours and other markers such as bold text, but that
opens a considerable can of worms with detecting in all systems and
configurations if that can be done. I have been told that some of these
situations are quite tricky and is not as easy as checking for tty support.
If
We just merged changes to the PEP with a detailed runtime API specification.
Highlights are that:
- The new type should have an `inspect.Signature`- inspired structured API
- It should have a backward-compatible interface with the `__args__` and
`__params__`
- As with the PEP 604 union syntax,
On 1/18/22 10:43 AM, Mats Wichmann wrote:
> A thought - how about omitting the underline line if the
> to-be-underlined part would be the whole line?
I would also like that change -- when the underlining is a portion of the whole it's quite useful, but when it's the
whole line it's a lot of
"When printing tracebacks, the interpreter will now point to the exact
expression that caused the error instead of just the line."
I get the motivation for better error messages, but there are scenarios
where you can't provide useful new information. I've been lax in
getting to testing the
On Tue, Jan 18, 2022 at 9:43 AM Richard Damon
wrote:
>
>
> On Jan 18, 2022, at 11:34 AM, Guido van Rossum wrote:
>
>
> At best it shows that deprecations are complicated no matter how well you
> plan them. I remember that "noisy by default" deprecation warnings were
> widely despised.
>
> On
> On Jan 18, 2022, at 11:34 AM, Guido van Rossum wrote:
>
>
> At best it shows that deprecations are complicated no matter how well you
> plan them. I remember that "noisy by default" deprecation warnings were
> widely despised.
>
>> On Tue, Jan 18, 2022 at 6:49 AM Antoine Pitrou wrote:
On 1/18/2022 2:44 PM, Antoine Pitrou wrote:
We propose to revert the following 2 changes in Python 3.11 and
postpone them in a later Python version, once most projects will be
compatible with these changes:
* Removal of unittest aliases (bpo-45162): it broke 61 Fedora packages
* Removals from
At best it shows that deprecations are complicated no matter how well you
plan them. I remember that "noisy by default" deprecation warnings were
widely despised.
On Tue, Jan 18, 2022 at 6:49 AM Antoine Pitrou wrote:
> On Tue, 18 Jan 2022 15:17:41 +0100
> Victor Stinner wrote:
> > Hi,
> >
> >
On Tue, 18 Jan 2022 15:17:41 +0100
Victor Stinner wrote:
> Hi,
>
> My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on
> updating Python 3.10 to Python 3.11 in Fedora, but some specific
> Python 3.11 incompatible changes are causing more troubles than
> others:
>
Hi,
My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on
updating Python 3.10 to Python 3.11 in Fedora, but some specific
Python 3.11 incompatible changes are causing more troubles than
others:
https://discuss.python.org/t/experience-with-python-3-11-in-fedora/12911
We propose to
How does someone know if a database is corrupted? Why is a separated
script needed?
A single script cannot automatically detect a corrupted database and
load the latest snapshot?
How is different from simply copying the whole database file?
Victor
--
Night gathers, and now my watch begins. It
Hello Victor :)
> Do you ask us our opinion on the Python API that you propose? Or if
the whole feature is worth it?
Latter must be done first :)
> Can you please show me a short full example opening a database with
automatic snapshot recovery (with your proposed API)?
The following codes are
Hi Dong-hee,
Can you please show me a short full example opening a database with
automatic snapshop recovery (with your proposed API)?
Do you ask us our opinion on the Python API that you propose? Or if
the whole feature is worth it?
Victor
On Tue, Jan 18, 2022 at 2:41 AM Dong-hee Na wrote:
>
Hi,
I made the following changes to the PEP since the version 1 (November 30):
* Elaborate the HPy section and add a new "Relationship with the HPy
project" section
* Elaborate which projects are impacted and which changes are needed
* Remove the PyPy section
The PEP can be read online:
30 matches
Mail list logo
