ify any CPython internals, so it looks like that
> test_typing_pydoc exposed some bug that has existed before it. Any help
> tracking that down is welcome :)
>
> Yury
> _______
> Python-Dev mailin
phane
Call For Proposals
==
This is the official call for sessions for the Python devroom at FOSDEM 2017.
FOSDEM is the Free and Open source Software Developers' European Meeting, a free
and non-commercial two-day week-end that offers open source contributors a place
to meet, s
ptions are summarized in
http://bugs.python.org/issue25458#msg283073 and the message after that one.
Apart from the options, I'd like to know if I must solve the 2nd problem
(error handling), too, or it can be handled in a separate ticket.
--
Regards,
Ivan
___
ptions are summarized in
http://bugs.python.org/issue25458#msg283073 and the message after that one.
Apart from the options, I'd like to know if I must solve the 2nd problem
(error handling), too, or it can be handled in a separate ticket.
--
Regards,
Ivan
___
Re: [Python-Dev] Asking for feedback about fixing `ftplib' (issue25458)
On 25.12.2016 17:21, Giampaolo Rodola' wrote:
From what I understand the problem should be fixed in urllib so that
it always closes the FTP connection. I understand this is what happens
in recent 3.x versions but
Re: [Python-Dev] Asking for feedback about fixing `ftplib' (issue25458)
On 28.12.2016 21:02, Giampaolo Rodola' wrote:
On Wed, Dec 28, 2016 at 3:57 PM, Ivan Pozdeev <mailto:v...@mail.mipt.ru>> wrote:
On 25.12.2016 17:21, Giampaolo Rodola' wrote:
From what
'returns' (return type
hint) attribute set to None.
--
Valentin
___________
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
print(t.body[0].returns)
> <_ast.NameConstant object at 0x10a900f28>
> >>> print(t.body[0].returns.value)
> None
My bad, thank you my King. ;)
--
Valentin
___
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
, on pypi rather than have them tied into the Python release
cycle. If YMMV so be it.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
___
Python-Dev mailing list
Python-Dev@
ation basically
means you can use GitHub to submit changes instead of uploading patches).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pytho
Hi Python Developers,
print() function has a slight design issue, when user gives start and end
positions of character array.Issue: >>> str_ary="abcdef" >>> print(str_ary[1])
b >>> print(str_ary[4]) e >>> print(str_ary[1:4]) bcd >>>
In the
an
implementation in that way should be done explicitly (via including a
utility class or using a decorator like functools.total_ordering), not as
side-effect of an (unnecessary) protocol declaration.
_______
Python-Dev mailing list
Python-Dev@python.org
h
that implicit subtyping is
> preferred (especially for user defined protocols),
> then this certainly could be done.
>
Yes, I believe it would be good to mention that.
_______
Python-Dev mailing list
Python-Dev@python.org
https://mail.python
are expected to automatically detect that a class
implements a given protocol. So while it's possible to subclass a protocol
explicitly, it's not necessary to do so for the sake of type-checking."
___
Python-Dev mailing list
Python-De
Hi.
Here's PEP 545, ready to be reviewed!
This is the follow-up to the "PEP: Python Documentation Translations" thread on
python-ideas [1]_,
itself a follow-up of the "Translated Python documentation" thread on
python-dev [2]_.
This PEP describes the steps to
tions)
--
Julien Palard
[https://mdk.fr](https://mdk.fr/)___
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
quot; and "French as spoken in France"). But when
the region subtag actually adds information, for example "pt-BR"
for "Portuguese as spoken in Brazil", it should be kept.
==
?
Bests,
--
Julien Palard
https://mdk.fr___
translation independently of the way they send us
translations. (It even work for paper…).
.. [1] PEP 512 -- Migrating from hg.python.org to GitHub
(https://www.python.org/dev/peps/pep-0512/#a-bot-to-enforce-cla-signing)
--
Julien Palard
https://mdk.fr_______
P
ellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
_______
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org
On 21/04/2017 16:03, Guyzmo via Python-Dev wrote:
On Fri, Apr 21, 2017 at 11:47:24AM +0200, Justus Schwabedal wrote:
At least I think it's a bug. Maybe it's a feature..
it's indeed a feature.
I possibly found a bug in class __init__ and would like to fix it
technically
On 09/05/2017 18:05, Ethan Furman wrote:
A comment on a recent SO answer [1] wondered why my aenum library wasn't
mentioned in the docs to help guide people that needed/wanted more
advanced Enum options to it. I responded that Python was not in the
habit of mentioning third-party librari
ading [1] is this
paragraph:
If you’re short on time, you can also email documentation bug reports
> to d...@python.org (behavioral bugs can be sent to
python-l...@python.org).
> ‘docs@’ is a mailing list run by volunteers; your request will be
noticed,
> though it may take
we stick on our notation. They are not against changing and looks like
they're OK with our notation:
https://github.com/rtfd/readthedocs.org/issues/2763
--
Julien Palard
https://mdk.fr___
Python-Dev mailing list
Python-Dev@python.org
https://mai
there is the Peephole for that, it's a small optimizer in the compiler.
On 05/24/2017 08:07 PM, Ben Hoyt wrote:
Hi folks,
I was looking at some `dis` output today, and I was wondering if anyone has
investigated optimizing Python (slightly) by adding special-case bytecodes
for c
s I'm actually touching code
relevent to this again.
Broadly the proposal looks good to me. It does help one of the two
cases I care about, and does no serious harm.
For a command line Python script, making sure Python itself uses UTF-8
for the C locale is sufficient, and setting LC_CTYPE so s
ises SystemExit and undo_something() raises
> KeyError, the final exception has type KeyError.
For Python 2.7, I've used the following idiom, which always masks
errors from the undo:
do_something()
try:
do_something_other()
except:
try:
Thanks for replying to my points!
On 12/06/2017, Nick Coghlan wrote:
>
> `PYTHONIOENCODING=:strict` remains the preferred way of forcing strict
> encoding checks on the standard streams, regardless of locale.
Then the user of my script has to care that it's written in Pytho
o for you, ask
what you can do for our language.
Mark Lawrence
---
This email has been checked for viruses by AVG.
http://www.avg.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
reviewing submissions, but maybe it just
got overlooked?
You can find the pull request at [2].
[1] https://docs.python.org/devguide/pullrequest.html#reviewing
[2] https://github.com/python/cpython/pull/1698
Some core developer has to decide if the new feature should be added,
and if so, what the API
t;> Emergency Response Division
>> NOAA/NOS/OR&R(206) 526-6959 voice
>> 7600 Sand Point Way NE (206) 526-6329 fax
>> Seattle, WA 98115 (206) 526-6317 main reception
>>
>> chris.bar...@noaa.gov
>>
>>
e experiments I did suggest that if you set it high
> enough for x += y to trigger it, then it will also be
> triggered in Joe's case.
>
> BTW, isn't there already a similar optimisation somewhere
> for concatenating strings? Does it still exist? How does
> it avoid this
er thread, but not a mix.
That is:
Thread 1: d.update({“a”: 1, “b”: 1})
Thread 2: d.update({“a”: 2, “b”: 2})
The result should have d[“a”] == d[“b”].
This can already end up with a mix of the two when “d” has keys that are
objects that implement __eq__ in Python, because the interpret
`int`, and the rest of which are bound to `Ts`. And this is indeed
something we haven't talked about explicitly how to specify yet.
Most of the discussion of PEP 646 has taken place on typing-sig, so I'll start
a new thread there to discuss this.
_____
C++ (was accepted into C++23), and
contains a decent overview of how other languages solve the same thing.
Even though the approach there is probably not applicable (as all python types are
implicitly `Optional` in the sense of "can be None", i.e. that API would have
to be added al
ogramming?), users encounter data that
is structured as dicts nested multiple levels. This is often out of
the user's control, as the dict is returned by reading a JSON value
whose structure is controlled by some other framework (often not
specific to Python).
For example, if we h
> Hi,
>
> This script is currently not written in Python and hardcodes paths that are
> incorrect on virtual environments and relocated installs, so it would make
> sense
> to rewrite it in Python, using sysconfig.
>
> That does not require it to be exposed as a module,
string is (vacuously but correctly) a substring of any string. This may
be inconvenient sometimes (as you say) but it is the logically correct
behaviour. Just as the modulus operator for ints returns the
mathematically correct result (unlike in some languages such as C / C++)
even though this
have used NFC rather than NFKC. Not sure if it's too late to fix
this "oops" in future Python versions.
Alex
On Sun, Nov 14, 2021 at 9:17 AM Christopher Barker
wrote:
> On Sat, Nov 13, 2021 at 2:03 PM wrote:
>
>> def 𝚑𝓮𝖑𝒍𝑜():
>>
>> try:
>>
*args:
> *Ts`) that after all we may actually want to allow. This would affect
> static type checkers only, there's no change in the grammar or runtime
> associated with lifting this restriction. See
> https://github.com/python/peps/pull/2125
>
> I presume the SC is okay with
ter all we may actually want to allow. This would affect
>> static type checkers only, there's no change in the grammar or runtime
>> associated with lifting this restriction. See
>> https://github.com/python/peps/pull/2125
>>
>> I presume the SC is okay with
On 21/11/2021 11:04, Paul Moore wrote:
On Sun, 21 Nov 2021 at 07:50, Christopher Barker wrote:
It's becoming harder and harder for people not particularly interested
in static typing to simply ignore it
(Raises hand.) +1
Rob Cliffe
___
Pytho
x27;s fine.
Rob Cliffe___
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@pyt
t the purpose of annotations had
not really been specified as being about typing in the first place.
It looks to me like Chris has identified in PEP 563 what is
potentially the earliest reference (in an accepted PEP) to the idea
that non-typing uses of annotations are to be discouraged.
--
Osc
at 3:03 PM, Serhiy Storchaka wrote:
28.11.21 17:13, Skip Montanaro пише:
That is not entirely true:
https://github.com/python/cpython/pull/29639#issuecomment-974146979
The only places I've seen "if 0:" or "if False:" in live code was for
debugging. Optimizing that
zèle". [Charles-Maurice de Talleyrand]
Rob Cliffe_______
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
ful contributions
from users.
-CHB
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
___
Python-Dev mailing list --pyt
probably break objects which intentionally lie about their class.
> (Mocks? Stubs? Proxies?)
https://mail.python.org/pipermail/python-dev/2015-October/141953.html
<https://mail.python.org/pipermail/python-dev/2015-October/141953.html> is an
old thread about the difference between typ
> On 10 Dec 2021, at 14:40, Steven D'Aprano wrote:
>
> On Thu, Dec 09, 2021 at 05:19:00PM +0100, Ronald Oussoren wrote:
>
>> https://mail.python.org/pipermail/python-dev/2015-October/141953.html
>> is an old thread about the difference between type(x)/Py_TYP
I've just updated the original Immortal Instances PR with a bunch of tricks
that I used to achieve as much performance parity as possible:
https://github.com/python/cpython/pull/19474 . You can see the details along
with some benchmarks in the PR itself.
This should address a bunch o
tiple `_` is a runtime
error. Maybe it would make too much of a mess.
After some testing evidently mypy only applies its knowledge sometimes anyway:
https://github.com/python/mypy/issues/11807
___
Python-Dev mailing list -- python-dev@python.o
efinite +1 on new callable
syntax for me.
p.s. I'm +0.5 on | binding tighter than ->
_______
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/pyt
Hi all,
I submitted my first PR against Python a month or so ago and was wondering
if someone could take a quick look at it and let me know if anything needs
to be fixed before it can be merged.
It's a pretty simple change (mostly just boilerplate delegation) that
allows SpooledTemporar
workshopping it in typing-sig,
>> so
>> > as PEP 1 requires we're asking for some feedback here too before
>> submitting
>> > it to the steering council.
>> >
>> > If you have time over the next couple of weeks, please take a look at
>&g
correct.
In any case, this is definitely something we should explain better in the
PEP. I'll make a TODO for myself to write something on this once Pradeep
and Guido have confirmed whether my understanding is correct.
___
Python-Dev mailing list
We've got to the stage now with PEP 646 that we're feeling pretty happy
>>> > with it. So far though we've mainly been workshopping it in
>>> typing-sig, so
>>> > as PEP 1 requires we're asking for some feedback here too before
>>> submittin
rray[*Ts1], y: Array[*Ts2]) as the
example? That seems unambiguous since the two positional arguments are
given separately.
Sorry, yes!
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mai
ed, Jan 12, 2022 at 5:04 PM Guido van Rossum
>> wrote:
>>
>>> On Wed, Jan 12, 2022 at 4:57 AM Petr Viktorin
>>> wrote:
>>>
>>>> Matthew Rahtz wrote:
>>>> > Hi everyone,
>>>> >
>>>> > We've got to t
type aliases and should be
>>> changed to "type argument list". The last one is less clear, I can't quite
>>> parse out what it's trying to say.
>>>
>>> On Wed, Jan 12, 2022 at 5:04 PM Guido van Rossum
>>> wrote:
>>>
>&g
> Even less, actually.
> The PEP doesn't make a very clear distinction between invalid Python
> syntax vs. invalid type annotation, so I wanted to check if we're on the
> same page here: the newly valid syntax will be subject to PEP 387.
> We clearly are on the same pa
y Warsaw wrote:
> > Hello Mark, Matthew, Pradeep, Vincent, and Guido,
> >
> > The Python Steering Council discussed the latest version of PEP 646
> (Variadic Generics) at our last meeting, and have unanimously decided to
> accept the PEP. Congratulations!
> >
>
roved
>> from core-devs or triage members but not merged yet.
>>
>
>> > I know "drive by approvals" are annoying but I think it is
>> unfortunately part of open source projects.
>> >
>>
>> Sorry, but I don't think so.
>>
>
ges differently:
> > first fix Cython, and *then* introduce the change.
> >
> > - (1) Propose a Cython PR and get it merged
> > - (2) Wait until a new Cython version is released
> > - (3) If possible, wait until numpy is released with regenerated Cython
> code
> &g
roblem right now is the pressure put on Cython maintainers to fix
> > Cython as soon as possible. IMO core developers who introduce
> > incompatible changes should be more involved in the Cython changes,
> > since Cython is a **key component** of the Python ecosystem. IMO
> &
reduce your maintenance burden.
With better communication we could find ways to do that.
Returning to the issue that started this thread - how do you suggest we
proceed with the exc_info change?
Irit
_______
Python-Dev mailing list -- python-dev@python.org
T
be used and
tested with pre-releases of CPython, although possibly with less performance.
Ronald
>
> Maybe we should advertise the two modes more. And make sure that both work.
> There are certainly issues with the current state of the "limited API"
> implementation
anning on checking in CI)
> * some strings may never get used for any given ./python invocation
> (not that big a difference though)
The first two cons can probably be fixed by adding some indirection, with some
markers at the place of use and a script that uses those to generate the
C defin
e
>>> does that leave pythoncapi_compat?
>> If you look at pythoncapi_compat.h, it provides backports for
>> recently-introduced public APIs such as PyObject_CallOneArg().
>
> Yes.
> On older Python versions, where the public API wasn't yet available, those
Hi folks, as illustrated in faster-cpython#150 [1], we have implemented a
mechanism that supports data persistence of a subset of python date types with
mmap, therefore can reduce package import time by caching code object. This
could be seen as a more eager pyc format, as they are for the
, if you immortalize your heap before forking (using the techniques in:
https://github.com/python/cpython/pull/31489) then you'll end up removing the
vast majority of scenarios where CoW takes place. I can look into writing a new
technical article for Instagram with more up to date info but
platform
> definition.
CTypes is hardware specific, although through libiff. There’s also intermittent
discussions about support for ancient hardware platforms. Would we block a
release when (for example) support for Linux on sparc32 is broken?
Ronald
—
Twitter / micro.blog: @ronaldou
class definition,
changing it afterwards is possible but has no effect (“class Foo: pass;
Foo.__slots__ = 42”). This surprised my recently and I have no idea if this
feature is ever used.
Ronald
>
> ___
> Python-Dev mailing list -- python
e that
value in the __slots__ attribute of the class
That way the value of the attribute reflects the slots that were created while
not breaking code that uses __slots__ and doesn’t change the value after class
creation.
Ronald
>
>
>
> On Fri, Mar 18, 2022 at 6:57 AM Ronald Ouss
7;D' is not defined
I think we should change import * to exclude the __future__ import objects, and
perhaps also to not show them in dir(x). Any objections?
This came up in the discussion about https://bugs.python.org/issue26120 . See
the attached PR for a technique we can use to identify tho
didn't - in either case it's not an interesting part of the
module's API).
___
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.py
release.
If the changed happens, would PyTorch still be able to use the eval frame API?
Or would it prevent from being used entirely?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https
P, but some kind of:
>
> "policy for the stdlib" document in which we could capture the primary points
> of view, places where there's consensus, etc. would be helpful to keep us
> retreading this over and over again.
>
> I suggest this without the bandwidth to act
Got it, thanks for the clarifications!
Tracking 3.x Python versions is fine. We already need to do that to support
things like new bytecodes, and PyTorch supports an explicit list of 3.x Python
versions with separate builds for each.
Tracking 3.x.y Python versions would be much more painful
;>
>>
>> Once
>> https://mail.python.org/archives/list/python-committ...@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/
>>
>> <https://mail.python.org/archives/list/python-committ...@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/>
>> is c
ace
always -- but not actually imported until someone accesses/uses it.
The difficulty arises because in this case you need some kind of
placeholder for the "deferred import", but you need to avoid this
"deferred object" escaping and becoming visible to Python code without
be
its.
Carl
_______
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.o
Hi Barry,
On Fri, Apr 8, 2022 at 12:44 PM Barry Warsaw wrote:
>
> Start up overhead due to imports is a real problem for some class of
> applications, e.g. CLIs, and I’ve seen a lot of hacks implemented to get
> Python CLIs to be more responsive. E.g. getting from invocat
robably use it occasionally, but I don't feel a strong need for
it.
But I think your proposal is much stronger if you eliminate the
hoisting from it; with the hoisting I'd be -1. Out-of-source-order
execution like this is just quite surprising in the context of Python.
> 1. This would
please provide some input on this
Please ask the pyinstaller developers about this.
Ronald
—
Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an
UGH!
I thought there was a general understanding that when typing was added
to Python, there would be no impact, or at least minimal impact, on
people who didn't use it. (Raises hand.)
Now we see an(other) instance of intention creep.
Rob Cliffe
On 23/04/2022 02:13, Larry Hastings
;forward class" and
> "continue class".
I work on a Python static type checker.
I think a major issue with this proposal is that (in the
separate-modules case) it requires monkey-patching as an import side
effect, which is quite hard for both humans and static analysis tools
to re
rebound, as in plain name binding, when the second part
> is declared. I've stated that amidst my ramblings,
> but Nick Coghlan managed to keep it suscint at
> https://mail.python.org/archives/list/python-dev@python.org/message/DMITVTUIQKJW6RYVOPQXHD54VSYE7QHA/
I don't think name
olved is solely related to typing. Is it not
possible to solve it purely in the "typing world", rather than letting
it leak out and "infect" something basic in the core language like how
classes are declared? By "core language" I guess I mean &quo
lass" object into a real type. (Which almost certainly means C is
> now mutable.)
>
A problem with this trick is that you don’t know how large a class object can
get because a subclass of type might add new slots. This is currently not
possible to do in P
is proposal, other than the size of the type (as mentioned
earlier). The PyObjC meta class constructs both the Python class and a
corresponding Objective-C class in lock step. On first glance this forward
class proposal should not cause any problems here other than the size of the
type obje
> On 26 Apr 2022, at 20:52, Larry Hastings wrote:
>
>
>
> On 4/25/22 23:56, Ronald Oussoren wrote:
>> A problem with this trick is that you don’t know how large a class object
>> can get because a subclass of type might add new slots. This is currently
>>
ution to forward reference problems for users of static typing
(every module that imports something that might be a forward reference
would have to import its implementation also, turning every one-line
import of that class into two or three lines) and causes new problems
for every user of Python due to
; struct in C. Would you call what C does monkeypatching?
>
It is not analogous; it is a false analogy that obscures the issues with
this proposal in Python.
A C forward declaration (not to mention the full struct declaration also!)
is purely for the compiler; at runtime one can have a pointer
On 26/04/2022 20:48, Carl Meyer via Python-Dev wrote:
On Tue, Apr 26, 2022 at 1:25 PM Guido van Rossum wrote:
I also would like to hear more about the problem this is trying to solve, when
th real-world examples. (E.g. from pydantic?)
Yes please. I think these threads have jumped far too
e
already started adopting PEP 563) to the best future end state.
Particularly for libraries that want to support the full range of
supported Python versions.
Issues (1) and (2) can be resolved under PEP 649 by providing a way to
run the __co_annotations__ function without erroring on
not-yet-def
ge to the dis module that you mentioned did not change how
the disassembly of bytecode gets displayed. Rather, it added the
pseudo-instructions to the opcodes list so that we have access to their
mnemonics from python. This is a step towards exposing intermediate
compilation steps to python (for unit
> Would you be interested in being posted about my progress ?
>
> Best
>
> Matthieu
___
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/p
100% agree – dealing with 5 or more platforms for discussion groups is a
nightmare, and I tend not to follow any of them as closely for that reason.
From: Skip Montanaro
Date: Friday, July 15, 2022 at 9:26 AM
To: Petr Viktorin
Cc: python-dev@python.org
Subject: [SPAM] [Python-Dev] Re
.g. the WebAssembly group is: https://discuss.python.org/c/webassembly/28
And its corresponding RSS feed is:
https://discuss.python.org/c/webassembly/28.rss
Cheers,
Peter
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...
On 15/07/2022 16:09, Rob Boehne via Python-Dev wrote:
100% agree – dealing with 5 or more platforms for discussion groups is
a nightmare, and I tend not to follow any of them as closely for that
reason.
I agree. I don't mind having to use Discourse if I want to take part in
a discussio
I have built this on systems at work, that are populated by CAD guys who have
developed a good set of libraries to maintain in a linux distribution. Went
without a hitch.
I am trying to build this at home with an opensuse distribution. I am not
trying to do any modifications to python, now
1401 - 1500 of 1717 matches
Mail list logo
