ebase where you 'often' do these kinds of
> conversions? Is it in a performance-critical area?
I can't but it hasn't been performance critical.
Regards,
Simon
https://tools.ietf.org/id/draft-msporny-base58-01.html [1]
https://datatracker.ietf.org/doc/draft-faltstrom-base45
ibilities.
The signature(s) I had in mind for now are akin to:
> int.from_base(x, alphabet, padding_character)
and
> int.to_base(alphabet, padding_character)
Has any discussion on this been had previously (I searched around a bit), and if
not would this ma
ib. There are just too many different ways to do it. (For
example, what if the user isn't familiar with flask?)
On Mon, Aug 24, 2020 at 1:45 PM Simon wrote:
> > Fair enough. I guess the real question is, how much advantage is
> > RESTRequestHandler over directly subclassing Bas
> Fair enough. I guess the real question is, how much advantage is
> RESTRequestHandler over directly subclassing BaseHTTPRequestHandler?
> Maybe it'd be worth it just to simplify that case.
>
> ChrisA
Well, maybe an example would be more telling. Below is a basic usage of the
handler I wrote :
>
> > The standard library module http.server already has 2 request handlers,
> with SimpleHTTPRequestHandler and CGIHTTPRequestHandler, the first serves
> files from a directory, and the second executes CGI scripts.
> >
> > Two new handlers could be included in the standard library :
> >
> > - Web
The standard library module http.server already has 2 request handlers,
with SimpleHTTPRequestHandler and CGIHTTPRequestHandler, the first serves
files from a directory, and the second executes CGI scripts.
Two new handlers could be included in the standard library :
- WebhookRequestHandler : Wou
Python's 'in' keyword has already several use cases, whether it's for
testing inclusion in a set, or to iterate over that set, nevertheless, I
think we could add one more function to that keyword.
It's not uncommon to see star imports in some sources. The reason that
people use star imports are ma
Hello,
I'd like to propose an update to PEP8. Indeed, the 80 characters per line
guideline is, I feel, outdated.
I understand the need for it, back when monitors were small, and everyone
coded on terminals, but nowadays, I feel like that guideline is more of a
hinderance, and that it promotes poo
I was writing some python code earlier, and I noticed that in a code that
looks somwhat like this one :
try:
i = int("string")
print("continued on")
j = int(9.0)
except ValueError as e:
print(e)
>>> "invalid literal for int() with base 10: 'string'"
this c
Looking at the arguments regarding rendering existing code non-PEP-8-compliant,
I think if we were to make this change it should be made in Python 4.0, or
whatever the next backwards-incompatible version will be.
However, personally I disagree with the fundamental assertion that ALL_CAPS is
alw
Ok, as I thought I was missing something quite important in the process.
Thanks to everybody in here.
Le lun. 20 août 2018 à 15:53, Joao S. O. Bueno a
écrit :
> On Mon, 20 Aug 2018 at 04:49, Chris Angelico wrote:
> >
> > On Mon, Aug 20, 2018 at 5:34 PM, Simon De Greve
> w
tant feature of the lib (which is apparently the case here).
Le lun. 20 août 2018 à 09:29, Nathaniel Smith a écrit :
> On Mon, Aug 20, 2018 at 12:19 AM, Simon De Greve
> wrote:
> > Hello everyone,
> >
> > I'm quite new working with asyncio and thus maybe missing som
Hello everyone,
I'm quite new working with asyncio and thus maybe missing some things about
it, but wouldn't it be quite easier to have some iterables to support async
for loops "natively", since asyncio is now part of the Stdlib?
I've tried to work with asyncio while using discord.py, and has so
Hello all,
I was developing a script using an asyncio-based API, when I came across the
need to define an asynchronous lambda. I found this syntax does not currently
exist. Obviously I could have (and did) just write a regular coroutine, but for
simple one-line functions and such, I think an asy
On Sunday, May 14, 2017 at 3:05:46 AM UTC-4, Steven D'Aprano wrote:
>
> On Sun, May 14, 2017 at 04:07:44AM +, Simon Ramstedt wrote:
> > Hi, do you have an opinion on the following?
>
> Hi, and welcome, and of course we have an opinion! This is Python-Ideas,
&
Hi, thanks a lot for your feedback!
On Sun, May 14, 2017, 00:54 Brendan Barnwell wrote:
> On 2017-05-13 21:07, Simon Ramstedt wrote:
> > Hi, do you have an opinion on the following?
>
> My general opinion is that imitating JavaScript is almost always a
> bad
> idea
y
return z
return self
or alternatively *multiline lambdas*:
def MyClass(x):
self = ParentClass()
self.my_method = (y):
z = x + y
return z
return self
Cheers,
Simon
___
Python-ideas m
* Simon D. [2017-03-28 09:56:05 +0200]:
> The str integrated one also, but maybe confusing, which regexp lib is
> used ? (must be the default one).
>
Ok, this was a mistake, based on JavaScript memories… There is no regexp
aware functions around str, but some hint to go find your hap
a JavaScript-like syntaxe would be great, and I
feel it as asking too much… :
- it would naturally be highlihted differently ;
- it would not be the first (happy) similarity
(https://hackernoon.com/javascript-vs-python-in-2017-d31efbb641b4#.ky9it5hph)
- its a working integration, including flag matte
teral
notation.
And if only the default one does, it would still be won for the
beginers, and the majority of persons using the stdlib.
--
Simon Descarpentries
+336 769 702 53
http://s.d12s.fr
___
Python-ideas mailing list
Python-ideas@python.org
htt
e slower than string-based workflow (like .startswith)
but regexps can do the most and the least, so they are rapide to come up
with, once you started to think with them. As Python philosophy is to
spare brain-cycles, sacrificing CPU-cycles, allowing to easily use
regexps is a brain-cycle savior t
I feel I have to respond to this one.
More than half of what I suggested could have and should be implemented.
In particular the truthiness of non-boolean data and the lack of a
reasonable SQL syntax. Several other points have been discussed
endlessly on the internet but without a satisfactor
Oh one last thing (I hope), the argument for having the current slice
notation by Dijkstra, that it looks messy to have a loop where the
contents are never executed or can no longer be executed is ridiculous!
That *should* look messy. for range(1,1): means executing once to me. If
you had 1 bas
Hi Kyle,
I don't see the harm caused from having a do-while construct. Not the
most used construct but it is sometimes useful and not having it means
you need to either have a first time through marker or a break at the
end of a "while True:" loop.
I would say that None should also be non-b
o have the block closing
delimiters this way, is the need for a keyword (could be a command line
option) really the objection?
I'll have a detailed look at your colon link a bit later.
On 10/01/17 09:26, Chris Barker wrote:
On Mon, Jan 9, 2017 at 5:12 PM, Simon Lovell <mailto:simo
Thanks for the feedback guys. A few quick comments:
Re: Colons. I'm sure I've seen that FAQ before. I may be arrogant but I
can't take it seriously. Being "slightly" easier to read is hardly a
reason for a mandatory structure.
Re: PEP249. I thought I'd detailed quite a bit of what I thought s
than "Re: Contents of Python-ideas digest..."
Today's Topics:
1. Re: PEP 540: Add a new UTF-8 mode (INADA Naoki)
2. Python Reviewed (Simon Lovell)
3. Re: Python Reviewed (Chris Angelico)
--
Message
Python Reviewed
Having used a lot of languages a little bit and not finding satisfactory
answers to these in some cases often asked questions, I thought I'd join
this group to make a post on the virtues and otherwise of python.
The Good:
Syntactically significant new lines
Syntactical
. Thank you all for your time.
On 23 October 2016 at 02:45, David B wrote:
> I would use list comprehension even if there were some other way to
> translate as it is straight forward.
>
> On 10/22/16, Simon Mark Holland wrote:
> > Having researched this as heavily as I am capabl
ve not seen
discussion of this before, but if there is such a discussion I would
welcome being directed to it.
Thank you for your time.
Simon
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
30 matches
Mail list logo
