vulnerable/
Is there a workaround that Python and/or Python apps should be doing, or is
this just a matter of everyone on glibc 2.9+ needs to update their glibc?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/list
alternative, as crazy as it may sound, is to get an AWS-Free-Tier EC2
instance and develop on that.
Or, of course, buy an ancient used laptop and install linux natively.
Obviously none of these are ideal, but they may still be better for you than
waiting for a complete MinGW port of Python or a
u need some configure switch to test that your compiler
doesn't allow short bit fields, so your ctypes build at least skips that part
of _ctypes_test.c and test_bitfields.py, and maybe even doesn't allow them in
Python code.
>> test_short fails om AIX when using xlC in any case. H
On Mar 19, 2016, at 18:18, Guido van Rossum wrote:
>
> Second, https://github.com/python/typing/issues/186. This builds on
> the previous syntax but deals with the other annoyance of long
> argument lists, this time in case you *do* care about the types. The
> proposal is to al
On Mar 20, 2016, at 09:07, Michael Felt wrote:
>
>> On 2016-03-18 05:57, Andrew Barnert via Python-Dev wrote:
>> Yeah, C99 (6.7.2.1) allows "a qualified or unqualified version of _Bool,
>> signed int, unsigned int, or some other implementation-defined type", a
guide the
few remaining decisions. To help test the various options you could
temporarily add a _allow_bytes=GLOBAL_CONFIG_OPTION default argument to both
pathlib.__fspath__() and os.fspath(), with distinct configurable defaults for
each.
In the spirit of Python 3 I feel like bytes might not
of a string only example at
https://gist.github.com/mmysinger/0b5ae2cfb866f7013c387a2683c7fc39
After playing with and considering the 4 possibilities, anything where
__fspath__ can return bytes seems like insanity that flies in the face of
everything Python 3 is trying to accomplish. In particular
Ethan Furman stoneleaf.us> writes:
> On 04/14/2016 12:03 AM, Michael Mysinger via Python-Dev wrote:
> > In particular, one RichPath
> > class might return bytes and another str, or even worse the same class
might
> > sometimes return bytes and sometimes str. When will o
Donald Stufft stufft.io> writes:
> > On Apr 14, 2016, at 11:59 AM, Michael Mysinger via Python-Dev python.org> wrote:
> >
> > In essence, you will force me to pre-
> > wrap all RichPath objects in either os.fsencode(os.fspath(path)) or
> > os.fsdecode(os
If Python ever adopts the BCPL rule for implicit line continuation if the
last thing on a line is an operator (or if there's an open parentheses),
then the break-after-an-operator rule would be more persuasive.
;)
[IIRC, the BCPL rule was that there was an implicit continuation if the
gr
comandos, todo bien,
Igual con matplotlib requiere de varias dependencias (dateutils, numpy,
tornado, etc, ya las instales) antes de su instalación, pero ya en el editor de
Python, al ejecutar el código, me aparece el siguiente mensaje:
ImportError: No module named 'matplotlib'
a
On 05/05/2016 23:22, Stefan Krah wrote
Fredrik Lundh is also affected (and might not have received any mail,
same as me):
https://pypi.python.org/pypi/PIL
He might be, but clearly the Python community as a whole is not
impacted. From what I see the latest version of PIL that is
On 06/05/2016 00:06, Barry Warsaw wrote:
On May 05, 2016, at 11:58 PM, Mark Lawrence via Python-Dev wrote:
On 05/05/2016 23:22, Stefan Krah wrote
Fredrik Lundh is also affected (and might not have received any mail,
same as me):
https://pypi.python.org/pypi/PIL
Maybe, but then there
Is Type[C,D] allowed? Or should multiple types be restricted to TypeVar?
___
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
Type[...] item have been defined with a TypeVar(...,
bound=...), in which case multiple types aren't allowed with Type[...]?
On 14 May 2016 at 11:30, Guido van Rossum wrote:
> What would Type[C, D] mean?
>
> --Guido (mobile)
> On May 14, 2016 11:21 AM, "Peter Ludemann vi
owed. There is *usually* a
> good reason to use a type variable though -- without one the return type
> would be the base class. (But then again maybe that could be what you want,
> or you might not even have a return type, e.g. when the thing just gets
> thrown into the database.)
>
>
27;t belong. The extra effort to use the second space helps to
> emphasize the author's intent, and even subjectively make the period
> "more visible".
>
> But I agree with Guido. No Python contributors write poorly, so the
> real issues are consistency with past prac
im Golden, Mark "I've forgotten more
about Python on Windows than you'll ever know" Hammond and Andy "ditto"
Robinson I can't say that I'll lose too much sleep over it. As I suffer
insomnia on top of chronic fatigue syndrome, that is quite a statement
for me to ma
gt; Regardless of what name, I'm fairly sure people will call it whatever
>> the
>> > function to create it is called. So if the function is
>> > typings.distinguish_type(...), then distinguished will stick.
>> >
>> > Top-posted from my Windows Phone
thods = unicodeiter_methods,
> };
I checked and VC++ does actually support this, and it looks like they support
// comments as well. I don't think it fully supports all of the C99 features
- it appears
They just cherry picked some stuff. The C99 standard library does appear to b
On 28.06.2018 2:45, Ivan Pozdeev via Python-Dev wrote:
On 28.06.2018 2:31, Ivan Pozdeev via Python-Dev wrote:
On 28.06.2018 1:42, Steven D'Aprano wrote:
On Wed, Jun 27, 2018 at 05:52:16PM +0300, Ivan Pozdeev via
Python-Dev wrote:
What this means in practice is that assignments will
hensions
with side effects is ever a good idea, and Tim's examples did
nothing to change that.
--
Regards,
Ivan
___________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pyth
On 28.06.2018 2:44, Greg Ewing wrote:
Ivan Pozdeev via Python-Dev wrote:
for me, the primary use case for an assignment expression is to be
able to "catch" a value into a variable in places where I can't put
an assignment statement in, like the infamous `if re.match() is not
ng if the answers to such puzzles were
> >> presented when they're posed.
>
well, I think the point there was that it wasn't obvious without running
the code -- and that point is made regardless of the answer.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Respo
of those, so it'll be no big deal, but this thread started talking
about educators' take on this -- and as an educator, I think this really
does complicate the language.
Python got much of it's "fame" by being "executable pseudo code" -- its
been moving farther
se 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
_______
Python-Dev mailing list
Python-Dev@python.org
https://mai
gt; surely you don't teach them in a one day introductory class aimed at
> beginners?
>
> Here is the syllabus for a ten week course:
>
> https://canvas.uw.edu/courses/1026775/pages/python-100-course-syllabus
>
That would be mine ;-)
> Note that decorators and even re
On 02/07/2018 19:19, Guido van Rossum wrote:
Thank you all. I will accept the PEP as is. I am happy to accept
*clarification* updates to the PEP if people care to submit them as
PRs to the peps repo (https://github.com/python/peps), and that could
even (to some extent) include summaries of
some thoughts that were buried in my
subconscious. It's just that I couldn't come up with any rational
objections to "->".
Rob Cliffe
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Vi
eads like these -- and other documentation, etc
I find there is a lot of confusion about the word "generator", as it
implies a "thing that generates values on the fly" (like, say the range()
object.
But then, in Python, a generator is something that gets crated by a
generator func
On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico wrote:
> On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka
> wrote:
> > I believe most Python users are not
> > professional programmers -- they are sysadmins, scientists, hobbyists and
> > kids --
>
> [citation needed]
ead of := maybe => better
:= too close to other langs
Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Of the proposed syntaxes, I dislike identifer := expression less, but
I'd still rather not see it added.
___
Python-Dev
review.
This "clever" code is exactly what Perl burned itself on and what
Python, being its antithesis, was specifically designed to avoid.
if result := solution(xs, n):
# use result
It looks equally clear with the original code. This is not enough for
introducing a new synta
l principle that Chris Angelico has repeatedly mention applies
here: If you want (as I instinctively would)
while (command := input("> ")).lower() != "quit":
you can't express that in your iter version.
Regards
Rob Cliffe
___
On 04.07.2018 10:10, Nathaniel Smith wrote:
On Tue, Jul 3, 2018 at 11:07 PM, Serhiy Storchaka wrote:
04.07.18 00:51, Chris Angelico пише:
On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka
wrote:
I believe most Python users are not
professional programmers -- they are sysadmins, scientists
m now we won't be
able to after PEP 572 is implemented.
Some people make fun of Python's expression/statement dichotomy,
because hey don't you know that everything can be an expression,
functional languages are awesome hurhur, but I think Python's approach
is actually very elegant. P
On 05.07.2018 2:29, Nathaniel Smith wrote:
On Wed, Jul 4, 2018 at 4:10 PM, Ivan Pozdeev via Python-Dev
wrote:
On 04.07.2018 10:10, Nathaniel Smith wrote:
Right, Python has a *very strong* convention that each line should
have at most one side-effect, and that if it does have a side-effect
it
hard".
How many of the users are "professional" vs "amateur" programmers is
irrelevant. (E.g. while newbies are ignorant, pros are instead
constantly pressed for time.)
Python Zen rather focuses on making it easy to write correct code for
everyone, beginners and pros alike
On 05.07.2018 3:40, Ivan Pozdeev via Python-Dev wrote:
On 05.07.2018 2:29, Nathaniel Smith wrote:
On Wed, Jul 4, 2018 at 4:10 PM, Ivan Pozdeev via Python-Dev
wrote:
On 04.07.2018 10:10, Nathaniel Smith wrote:
Right, Python has a *very strong* convention that each line should
have at most
oved here".
Well, if no-one knows how to find something that can be improved, it
can't be improved :)
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.py
assume (sorry to be pedantic :-)) this is a typo for
while (m := match()) and (j := m.end()) != i:
...
Maybe we reached here the maximum acceptable complexity of a single
Python line? :-)
It's at my limit. But, as in an earlier example, I'd be tempted to do
&q
us will use them more than others, some
perhaps not at all.
Regards
Rob Cliffe
_______
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 05.07.2018 1:51, Victor Stinner wrote:
Hi,
Let's say that the PEP 572 (assignment expression) is going to be
approved. Let's move on and see how it can be used in the Python
stdlib.
I propose to start the discussion about "coding style" (where are
assignment expression
On 05.07.2018 2:52, Mike Miller wrote:
Recently on Python-Dev:
On 2018-07-03 15:24, Chris Barker wrote:
> On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico > On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka
>
> > I believe most Python users are not
> > pro
the letter "all capabilities" 'cuz I may've missed something.)
Should it?
Personally, I'm for the unpacking but against augmentation 'cuz it has
proven incomprehensible as per the 5 Jul 2018 04:22:36 +0300 letter.
--
Regards,
Ivan
_________
64.py AFAICS),
the change to `for' is fine.
_______
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/vano%40mail.mipt.ru
--
Reg
g
to prescribe coding style or thinking about which parts of the std lib
should be refactored to use it and which shouldn't.
There is no need to rush into making changes. Let them happen naturally.
--
Regards,
Ivan
_______
Python-Dev mailing li
On 05.07.2018 9:20, Steven D'Aprano wrote:
On Thu, Jul 05, 2018 at 05:33:50AM +0300, Ivan Pozdeev via Python-Dev wrote:
And https://mail.python.org/pipermail/python-dev/2018-June/154160.html
disproves the "chosen often these days in new languages".
Ivan, I think you may hav
... # obviously use x
# ":=" in the if "announces" that usually x is no longer used
# here, even if technically x is still defined
The construct for temporary variables is `with'. `if' carries no such
implications.
See my match/group PR for more concrete exa
On 05.07.2018 3:22, Chris Angelico wrote:
Python uses "as NAME" for things that
are quite different from this, so it's confusing
I wrote in
https://mail.python.org/pipermail/python-dev/2018-June/154066.html that
this is easily refutable.
Looks like not for everybody. Okay,
7;t by hardly anyone ever does / would.
A lot of the argument for this feature is that it doesn't really let you do
things you couldn't do before (like manipulate the local namespace in side
comprehensions, or the nonocal one, or...)
But this IS a silly game -- Python is highly dynamic, you c
On 06.07.2018 7:02, Chris Angelico wrote:
On Fri, Jul 6, 2018 at 12:48 PM, Alexander Belopolsky
wrote:
Python really has a strong C legacy and this is the area where I agree that
C designers made a mistake by picking a symmetric symbol (=) for an
asymmetric operation. On top of that, they
.
--
Regards,
Ivan
___
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
uilder_pattern) commonly used in Java.
(Though I worry about the presence of a Python example in that
Wikipedia page. :-)
According to https://en.wikipedia.org/wiki/List_comprehension#History,
the term's known from at least 1977 and comes from such influential
languages as NPL, Miranda an
On 07.07.2018 2:58, Ivan Pozdeev via Python-Dev wrote:
On 07.07.2018 2:31, Guido van Rossum wrote:
On Fri, Jul 6, 2018 at 4:19 PM Terry Reedy <mailto:tjre...@udel.edu>> wrote:
Since Guido, the first respondent, did not immediately shoot the
idea
down, I intend to flesh i
https://github.com/python/cpython/pull/8145
On 07.07.2018 3:33, Ivan Pozdeev via Python-Dev wrote:
On 07.07.2018 2:58, Ivan Pozdeev via Python-Dev wrote:
On 07.07.2018 2:31, Guido van Rossum wrote:
On Fri, Jul 6, 2018 at 4:19 PM Terry Reedy <mailto:tjre...@udel.edu>> wrote:
Si
ly that's pretty arbitrary.
Thanks to all of you who keep making 3.4 and 3.5 better,
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/p
d).
Bests,
--
Julien Palard
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
On 09.07.2018 1:32, Larry Hastings wrote:
On 07/08/2018 10:05 AM, Ivan Pozdeev via Python-Dev wrote:
I'll use this opportunity to remind you that 3.4 build is broken --
it can't be built from start to installer with the instructions given
because of outside factors (CPython has mig
s this still the case?
Shouldn't we encourage new Windows users (who may not even know the
distinction between the two architectures) to use the 64-bit version
of Python, since most likely they can?
The difficulty is that they *definitely* can use the 32-bit version,
and those few who a
Flury <https://twitter.com/TonyFlury/>*
___
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
uivalent
px, py, pz = position
name, phone, email, *other_info = contact
[snip]
total += tax # Equivalent: (total := total + tax)
Is it conceivable that some of these restrictions might be removed in a
future version of Python? If so, the PEP might include a note to this
effect.
tive in my book.
Victor
_______
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/vano%40mail.mipt.ru
_______
Python-De
t term anywhere else.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
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
_______
ing-point values, saving large quantities of
memory by having only one floating-point zero.
Steve Holden
On Thu, Jul 12, 2018 at 9:55 AM, Alex Walters mailto:tritium-l...@sdamon.com>> wrote:
> -Original Message-
> From: Python-Dev list=sdamon@python.org &l
Thanks Nick,
I'll adopt this approach when I update my teaching materials.
If I think of it, I"ll post here when I do that
-CHB
On Sun, Jul 15, 2018 at 12:21 AM, Nick Coghlan wrote:
> On 13 July 2018 at 15:30, Chris Barker via Python-Dev
> wrote:
> > On Mon, Jul 9,
*Hi Folks,Cc: Rebecca, pytypeThis is Adam Cataldo; I’m the engineering
manager for the Python team at Google. Rebecca Chen, our lead pytype
<https://github.com/google/pytype> contributor, and I are interested in
helping finalize PEP 484 if possible. To that end, we wanted to find ou
g/dev/peps/pep-0484/#acceptable-type-hints, type hints
may be classes, abstract base classes, types defined in the `types` and
`typing` modules, type variables, type aliases and None. Further in the
section you linked, PEP 484 also states, "Stub files have the same syntax
as regular Python mod
ble-type-hints, type
> hints may be classes, abstract base classes, types defined in the `types`
> and `typing` modules, type variables, type aliases and None. Further in the
> section you linked, PEP 484 also states, "Stub files have the same syntax
> as regular Python modules,&q
n what
the authors are still trying to finalize and how we can be useful. As
a conversation starter, we offered two issues in which pytype has some
personal stake.
Best,
Rebecca
P.S. Yes, Adam manages Python at Google.
On Mon, Jul 16, 2018 at 3:15 PM Guido van Rossum wrote:
>
> On Mon, Jul
On 17.07.2018 7:18, Radim Řehůřek wrote:
Hi all,
one of our Python projects calls for pretty heavy, low-level
optimizations.
We went down the rabbit hole and determined that having access to
PyList_GET_ITEM(list), PyInt_AS_LONG(int) and PyDict_GetItem(dict,
unicode) on Python objects
be some lessons learned there.
The key differences may be that numpy arrays are full-fledged python
objects, but they are not (generally) containers of python objects -- that
is, the actual values are i memory accessed via a C pointer. Whereas a
PyList holds pointers to Python objects, so even
ceanographer
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
___
Python-Dev mailing list
Pyt
of PEP 484, but it
> > could well be done as a separate PEP (perhaps an informational one?).
> > I hope you understand that I am not volunteering.
> An informational PEP sounds about right to me. Such a PEP could also
> include style recommendations like those from typeshed'
nd
>>> that I am not volunteering.
>>>
>> An informational PEP sounds about right to me. Such a PEP could also
>> include style recommendations like those from typeshed's CONTRIBUTING file (
>> https://github.com/python/typeshed/blob/master/CONTRIBUTING.
I don't think that's within the scope of PEP 484, but it
>> > could well be done as a separate PEP (perhaps an informational one?).
>> > I hope you understand that I am not volunteering.
>> An informational PEP sounds about right to me. Such a PEP could also
>> include
hout holding the
GIL there are definitely use cases where it is not, for example when there are
keys with a type implemented in python, or when the dict is modified in another
thread.
Ronald
_______
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyt
On 17.07.2018 19:44, Jussi Judin wrote:
Hi,
I have been fuzzing[1] various parts of Python standard library for Python 3.7
with python-afl[2] to find out internal implementation issues that exist in the
library. What I have been looking for are mainly following:
* Exceptions that are
hough that that's not the case, and
now you're in the defense.
--
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/l
Whatever you decide, please research existing practices and their
results so as not to repeat the same mistakes as others made before you.
In particular, http://meatballwiki.org/wiki/BenevolentDictator and
https://en.wikipedia.org/wiki/Anti-pattern .
It would be a waste if Python falls victim to
ido's
vacation :)
___
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
run out of
stack space?
The reason I’m looking into this is that the default stack size on macOS is
fairly small and I’d like to avoid crashing the interpreter when running out of
stackspace on threads created by the system (this is less of a risk on threads
created by Python itself because we
> On 30 Jul 2018, at 10:20, Victor Stinner wrote:
>
> The API leaking all implementation details will remain available as an opt-in
> option for Cython, cffi and debug tools. But this API will only be usable on
> the "slow" Python runtime, the one whi
Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
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
sue -- but what can you do?
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
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
__
On Wed, Aug 1, 2018 at 2:40 PM, Armin Rigo wrote:
> On 30 July 2018 at 22:19, Chris Barker via Python-Dev
> wrote:
> > Oh well. This is a serious usability issue -- but what can you do?
>
> I think that argument clinic knows if the built-in function is
> supposed to be a
ant the exception handling, you can define your own
>> declaration of PyList_Append() that does not have it. But personally, I'd
>> rather use try-except in my test code than manually taking care of cleaning
>> up (unexpected) exceptions.
>
> Exactly, that's the kind of
(id(v)).ob_refcnt
>
> The quoted code is what I was referring to in:
>
> ctypes & cffi likely wouldn't help as much in the case, since they
> don't eliminate the need to come up with custom code for parts 3 & 4,
> they just let you write that logic in Python
> On 6 Aug 2018, at 17:13, Stefan Behnel wrote:
>
> Ronald Oussoren via Python-Dev schrieb am 06.08.2018 um 15:25:
>>> On 5 Aug 2018, at 18:14, Nick Coghlan wrote:
>>> On 5 August 2018 at 18:06, Ronald Oussoren wrote:
>>>> I’m not sure if I understand thi
This is an appropriate topic for pyton-ideas:
https://mail.python.org/mailman/listinfo/python-ideas
not python-dev.
I'm sure you'll find interest in your idea there.
-CHB
On Wed, Aug 15, 2018 at 1:25 AM, Marko Ristin-Kaufmann <
marko.ris...@gmail.com> wrote:
> Hi python d
python used the "timsort" sorting routine:
https://en.wikipedia.org/wiki/Timsort
So you can look at that and confirm that this is correct behaviour (I'm
betting it is :-)
But in general, sorting is O(n log(n)) -- there are going to be more than n
comparisons.
If comparing is sl
FromSpec is that this can result in C extensions that
are binary compatible between python versions, which IMHO is less useful than
it used to be in the past thanks to CI/CD systems.
PyType_FromSpec also cannot deal with some esoteric use cases, such as defining
types with a cus
Hey Everyone!
I am new to this mailing list. I have experience with software development
in the medical device industry and SaaS technology solutions. I have primarily
worked with R, Java, and various unique and specific machine languages, but I
have recently picked up Python.
Part of
Oh! I’m so sorry haha. I thought this was a developers forum for users of
Python. So you are saying Python-list would be that type of forum?
-Kevin
Sent from my iPhone
> On Sep 1, 2018, at 1:48 PM, Brett Cannon wrote:
>
> Hi, Kevin! This mailing list is actually about the devel
g the source of an idea or
fact, or something of that nature. I can imagine a paper about computer
language design or some such might need to reference Python -- in which
case it should reference the Language Reference, I suppose. Maybe we should
have a DOI for each version of the standard docs.
us to agree on that, but there are still multiple reasons /
ways you might want to cite Python, and what you would want to cite would
be different.
Lets say one were to write an article about how different computer
languages express functional programming concepts -- you may want to cite
Python, bu
why this thread got sidetracked into
citation formats, that has nothing to do with it. Or as the op said, that's
"the easy part"
> Lets say one were to write an article about how different computer
> > languages express functional programming concepts -- you may want
Thanks Wes.
"""
> Python
>
> Guido van Rossum: Scripting the Web with Python. In "Scripting Languages:
> Automating the Web", World Wide Web Journal, Volume 2, Issue 2, Spring
> 1997, O'Reilly.
>
> Aaron Watters, Guido van Rossum, James C. Ahls
are
>> trying to solve.
>> *As a user, I am writing an academic paper and I need to cite Python. *
>>
>
ai'd still like to know *why* you need to cite python 0 I can imagine
multiple reasons, and that may influence the best document to cite.
> Let's throw reprod
y> def spam(**kwargs):
>> > print(kwargs)
>> >
>> > py> spam(**{"something arbitrary": 1, '\n': 2})
>> > {'something arbitrary': 1, '\n': 2}
>> >
>> >
>> > There is some discussion on P
1001 - 1100 of 1708 matches
Mail list logo