On Feb 25 2018, Chris Angelico wrote:
> On Sun, Feb 25, 2018 at 11:02 PM, Nikolaus Rath wrote:
>> On Feb 22 2018, Serhiy Storchaka wrote:
>>> 1. Inner generator expression:
>>>
>>> result = [y + g(y) for y in (f(x) for x in range(10))]
>>>
&g
On Feb 22 2018, Serhiy Storchaka wrote:
> 1. Inner generator expression:
>
> result = [y + g(y) for y in (f(x) for x in range(10))]
>
[...]
>
> And maybe there are other ways.
I think the syntax recently brough up by Nick is still the most
beautiful:
result = [ (f(x) as y) + g(y) for x i
On Jul 21 2017, David Mertz wrote:
> How implausible is it to write out the actual memory image of a loaded
> Python process?
That is what Emacs does, and it causes them a lot of trouble. They're
trying to move away from it at the moment, but the direction is not yet
clear. The keyword is "unexec
On Oct 11 2016, Nathaniel Smith wrote:
> On Tue, Oct 11, 2016 at 9:08 PM, INADA Naoki wrote:
>> From Python 3.4, bytearray is good solution for I/O buffer, thanks to
>> #19087 [1].
>> Actually, asyncio uses bytearray as I/O buffer often.
>
> Whoa what?! This is awesome, I had no idea that bytearr
On Sep 13 2016, Tim Peters wrote:
> [Terry Reedy ]
>>> Tim Peters investigated and empirically determined that an
>>> O(n*n) binary insort, as he optimized it on real machines, is faster
>>> than O(n*logn) sorting for up to around 64 items.
>
> [Nikolaus Rath
On Sep 11 2016, Terry Reedy wrote:
> Tim Peters investigated and empirically determined that an
> O(n*n) binary insort, as he optimized it on real machines, is faster
> than O(n*logn) sorting for up to around 64 items.
Out of curiosity: is this test repeated periodically on different
architecture
On Jun 21 2016, Serhiy Storchaka wrote:
> There is a design question. If you read file in some format or with
> some protocol, and the data is ended unexpectedly, when to use general
> EOFError exception and when to use format/protocol specific exception?
>
> For example when load truncated pickle
On Jun 16 2016, Nick Coghlan wrote:
> On 16 June 2016 at 09:39, Paul Moore wrote:
>> I'm willing to accept the view of the security experts that there's a
>> problem here. But without a clear explanation of the problem, how can
>> a non-specialist like myself have an opinion? (And I hope the secu
On Jun 09 2016, Larry Hastings wrote:
> On 06/09/2016 07:38 PM, Nikolaus Rath wrote:
>> On Jun 09 2016, Larry Hastings wrote:
>>> Nope, I want the old behavior back. os.urandom() should read
>>> /dev/random if getrandom() would block. As the British say, "it
&
On Jun 09 2016, Guido van Rossum wrote:
> I don't think we should add a new function. I think we should convince
> ourselves that there is not enough of a risk of an exploit even if
> os.urandom() falls back.
That will be hard, because you have to consider an active, clever
adversary.
On the oth
On Jun 09 2016, Larry Hastings wrote:
> On 06/09/2016 03:44 PM, Ethan Furman wrote:
>> On 06/09/2016 03:22 PM, Larry Hastings wrote:
>>> Okay, it's decided: os.urandom() must be changed for 3.5.2 to never
>>> block on a getrandom() call.
>>
>> One way to not block is to raise an exception. Since
On May 11 2016, Brett Cannon wrote:
> This PEP proposes a protocol for classes which represent a file system
> path to be able to provide a ``str`` or ``bytes`` representation.
[...]
As I said before, to me this seems like a lot of effort for a very
specific use-case. So let me put forward two hy
On Apr 13 2016, Ethan Furman wrote:
> On 04/13/2016 03:45 PM, Nikolaus Rath wrote:
>
>> When passing an object that is of type str and has a __fspath__
>> attribute, all approaches return the value of __fspath__().
>>
>> However, when passing something of t
On Apr 13 2016, Brett Cannon wrote:
> On Tue, 12 Apr 2016 at 22:38 Michael Mysinger via Python-Dev <
> python-dev@python.org> wrote:
>
>> Ethan Furman stoneleaf.us> writes:
>>
>> > Do we allow bytes to be returned from os.fspath()? If yes, then do we
>> > allow bytes from __fspath__()?
>>
>> De-
On Apr 13 2016, Ethan Furman wrote:
> (I'm not very good at keeping similar sounding functions separate --
> what's the difference between shutil.copy and shutil.copy2? I have to
> look it up every time).
Well, "2" is more than "" (or 1), so copy2() copies *more* than copy() -
it includes the me
On Apr 11 2016, Jon Ribbens wrote:
>> What I see is that you asked to break your sandbox, and less than 1
>> hour later, a first vulnerability was found (exec called with two
>> parameters). A few hours later, a second vulnerability was found
>> (async generator and cr_frame).
>
> The former was j
On Apr 10 2016, Jon Ribbens wrote:
> On Sat, Apr 09, 2016 at 02:43:19PM +0200, Victor Stinner wrote:
>>Please don't loose time trying yet another sandbox inside CPython. It's
>>just a waste of time. It's broken by design.
>>
>>Please read my email about my attempt (pysandbox):
>>h
On Apr 07 2016, Donald Stufft wrote:
>> On Apr 7, 2016, at 6:48 AM, Nikolaus Rath wrote:
>>
>> Does anyone anticipate any classes other than those from pathlib to come
>> with such a method?
>
>
> It seems like it would be reasonable for pathlib.Path to ca
On Apr 06 2016, Ethan Furman wrote:
> On 04/06/2016 11:15 PM, Greg Ewing wrote:
>> Chris Barker - NOAA Federal wrote:
>>> But fspath(), if it exists, would call __fspath__ on an arbitrary
>>> object, and create a new string -- not a new Path. That may be
>>> confusing...
>>
>> Maybe something like
Hello,
With the upcoming move to Git, I thought people might be
interested in some thoughts that I wrote down when learning Git
for the first time as a long-time Mercurial user:
http://www.rath.org/mercurial-for-git-users-and-vice-versa.html
Comments are welcome (but probably more appropriat
On Feb 01 2016, mike.romb...@comcast.net wrote:
" " == Barry Warsaw writes:
>> On Feb 01, 2016, at 11:40 AM, R. David Murray wrote:
>> I don't know about anyone else, but on my own development
>> systems it is not that unusual for me to *edit* the
>> stdlib files (to a
On Dec 04 2015, Victor Stinner wrote:
> Hi,
>
> I implemented 3 new optimizations in FAT Python: loop unrolling, constant
> folding and copy builtin functions to constants. In the previous thread,
> Terry Reedy asked me if the test suite is complete enough to ensure that
> FAT Python doesn't break
On Sep 16 2015, Terry Reedy wrote:
> On 9/16/2015 5:20 AM, Oleg Broytman wrote:
>
>> On Tue, Sep 15, 2015 at 07:44:28PM +, Augie Fackler
>> wrote:
>
>>> There are a lot of reasons to prefer one tool over another. Common ones are
>>> familiarity, simplicity, and power.
>>
>> Add here docu
On Sep 16 2015, Nikolaus Rath wrote:
> On Sep 16 2015, "R. David Murray" wrote:
>> On Wed, 16 Sep 2015 09:17:38 -0700, Nikolaus Rath wrote:
>>> On Sep 16 2015, "R. David Murray" wrote:
>>> > The DAG plus git branches-as-labels *fits in my hea
On Sep 17 2015, "Stephen J. Turnbull" wrote:
> Nikolaus Rath writes:
>
> > Hmm, that's odd. As far as I know, the difference between the hg and git
> > DAG model can be summarized like this:
> >
> > * In git, leaves of the DAG must be assigned a
On Sep 16 2015, "R. David Murray" wrote:
> On Wed, 16 Sep 2015 09:17:38 -0700, Nikolaus Rath wrote:
>> On Sep 16 2015, "R. David Murray" wrote:
>> > The DAG plus git branches-as-labels *fits in my head* in a way that the
>> > DAG plus named-branche
mark bar
> creates 2 bookmarks. If I then check in a change, I guess *both*
> bookmarks move.
No, only the active bookmark moves automatically:
$ hg bookmark foo
$ hg bookmark bar
$ hg log -r tip
changeset: 0:d1c121e915b8
bookmark:bar
bookmark:foo
tag: tip
user:Nikolaus
On Sep 16 2015, "R. David Murray" wrote:
> The DAG plus git branches-as-labels *fits in my head* in a way that the
> DAG plus named-branches-and-other-things does not.
Hmm, that's odd. As far as I know, the difference between the hg and git
DAG model can be summarized like this:
* In git, leave
On Sep 16 2015, Chris Angelico wrote:
> With git, there are infinite workflows possible - you aren't forced to
> have a concept of "central server" and "clients" the way you would
> with SVN. Mercurial's called a DVCS too, so presumably it's possible
> to operate on a pure-peering model with no ce
On Sep 16 2015, Paul Moore wrote:
> On 16 September 2015 at 06:10, Stephen J. Turnbull wrote:
>> The only thing that hg really lost badly on
>> IMO was "named branches", and that's been fixed with bookmarks.
>
> FWIW, I still find bookmarks confusing to use compared to git
> branches. I don't k
On Sep 16 2015, Chris Angelico wrote:
> On Wed, Sep 16, 2015 at 5:44 AM, Augie Fackler wrote:
>>> but git is still better at it: ``git add -p``
>>> allows me to review and edit patches before commit while ``hg record``
>>> commits immediately.
>>
>> FWIW, I totally *get* wanting a staging area. T
On Sep 05 2015, Nick Coghlan wrote:
> On 5 September 2015 at 12:36, Nikolaus Rath wrote:
>> Hi Nick,
>>
>> You are giving
>>
>> runcommand(sh(i"cat {filename}"))
>>
>> as an example that avoids injection attacks. While this is true, I
Hi Nick,
You are giving
runcommand(sh(i"cat {filename}"))
as an example that avoids injection attacks. While this is true, I think
this is still a terrible anti-pattern[1] that should not be entombed in
a PEP as a positive example.
Could you consider removing it?
(It doubly wastes resources
On Sep 04 2015, "Eric V. Smith" wrote:
> I've made a number of small changes to PEP 498. I don't think any of the
> changes I've made in the last week are substantive. Mostly I've
> clarified how it works and removing some limitations. The only
> meaningful change is that expressions are now surro
On Aug 16 2015, Paul Moore wrote:
> 2. By far and away the most common use for me would be things like
> print(f"Iteration {n}: Took {end-start) seconds").
I believe an even more common use willl be
print(f"Iteration {n+1}: Took {end-start} seconds")
Note that not allowing expressions would tur
On Aug 08 2015, Nikolaus Rath wrote:
> On Aug 08 2015, Nick Coghlan wrote:
>> On 8 August 2015 at 11:39, Eric V. Smith wrote:
>>> Following a long discussion on python-ideas, I've posted my draft of
>>> PEP-498. It describes the "f-string" approac
On Aug 08 2015, Nick Coghlan wrote:
> On 8 August 2015 at 11:39, Eric V. Smith wrote:
>> Following a long discussion on python-ideas, I've posted my draft of
>> PEP-498. It describes the "f-string" approach that was the subject of
>> the "Briefer string format" thread. I'm open to a better title
mpound_stmts.html#coroutines
>
> Perhaps, it's a browser cache issue?
>
> Yury
>
> On 2015-08-02 12:38 AM, Nikolaus Rath wrote:
>> Hello,
>>
>> Looking at the language reference for 3.5.0b4, I noticed that it
>> mentions neither async nor await.
>>
&
Hello,
Looking at the language reference for 3.5.0b4, I noticed that it
mentions neither async nor await.
Is this still going to get updated, or will the only documentation
consist of the PEP itself? I think having a Python release recognize
keywords that are not mentioned in the language referen
On Jul 31 2015, Mark Lawrence wrote:
> There are over 400 issues on the bug tracker that have not had a
> response to the initial message, roughly half of these within the last
> eight months alone. Is there a (relatively) simple way that we can
> share these out between us to sort those that are
On Jul 27 2015, Lennart Regebro wrote:
> That you add one hour to it, and the datetime moves forward one hour
> in actual time? That's doable, but during certain circumstance this
> may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
>
> Or do you expect that adding one hour will increase th
On Jul 22 2015, Nick Coghlan wrote:
> On 22 July 2015 at 13:23, Nikolaus Rath wrote:
>> If it were up to me, I'd focus all the resources of the PSF on reducing
>> this backlog - be that by hiring some core developers to work full-time
>> on just the open bugtrack
On Jul 21 2015, Nick Coghlan wrote:
> All of this is why the chart that I believe should be worrying people
> is the topmost one on this page:
> http://bugs.python.org/issue?@template=stats
>
> Both the number of open issues and the number of open issues with
> patches are steadily trending upward
On Apr 21 2015, Paul Sokolovsky wrote:
> Hello,
>
> On Tue, 21 Apr 2015 08:05:59 -0700
> Nikolaus Rath wrote:
>
>> On Apr 20 2015, Chris Angelico wrote:
>> > Maybe it'd be of value to have a quick "code stripper" that takes
>> > away all th
On Apr 20 2015, Chris Angelico wrote:
> Maybe it'd be of value to have a quick "code stripper" that takes away
> all the annotations, plus any other junk/framing that you're not
> interested in, and gives you something you can browse in a text
> editor?
If you need to preprocess your source code
On Apr 20 2015, Harry Percival wrote:
> My first reaction to type hints was "yuck", and I'm sure I'm not the only
> one to think that. viz (from some pycon slides):
>
> def zipmap(f: Callable[[int, int], int], xx: List[int],
>yy: List[int]) -> List[Tuple[int, int, int]]:
>
> a
Nick Coghlan writes:
As some examples of where bilingual computing breaks down:
* My NFS client and server may have different locale settings
* My FTP client and server may have different locale settings
* My SSH client and server may have different locale settings
*
Chris Barker writes:
> What I fail to see is why it's better to raise an exception and point users
> to a better way, than to simply provide an optimization so that it's a mute
> issue.
>
> The only justification offered here is that will teach people that summing
> strings (and some other objects
Hello,
The following commit-ready patches have been waiting for review since
May and earlier.It'd be great if someone could find the time to take a
look. I'll be happy to incorporate feedback as necessary:
* http://bugs.python.org/issue1738 (filecmp.dircmp does exact match
only)
* http://bugs.
Ben Hoyt writes:
> So here's the ways in which option #2 is now more complicated than option #1:
>
> 1) it has an additional "info" argument, the values of which have to
> be documented ('os', 'type', 'lstat', and what each one means)
> 2) it has an additional "onerror" argument, the signature of
Ben Hoyt writes:
> Thanks for the clarifications and support.
>
>> Ah, the wording in the PEP says "Linux, Windows, OS X". Superficially,
>> that said "everywhere" to me. It might be worth calling out
>> specifically some examples where it's not available without an extra
>> system call, just to m
Victor Stinner writes:
> Le 15 juin 2014 02:42, "Benjamin Peterson" a écrit :
>> On Sat, Jun 14, 2014, at 15:39, Nikolaus Rath wrote:
>> > It seems to me that a much cleaner solution would be to simply declare
>> > _pyio's readinto to only work
Nick Coghlan writes:
> On 15 June 2014 14:57, Nikolaus Rath wrote:
>> On 06/14/2014 09:31 PM, Nick Coghlan wrote:
>>> On 15 June 2014 10:41, Benjamin Peterson wrote:
>>>> On Sat, Jun 14, 2014, at 15:39, Nikolaus Rath wrote:
>>>>> It seems to me th
On 06/14/2014 09:31 PM, Nick Coghlan wrote:
> On 15 June 2014 10:41, Benjamin Peterson wrote:
>> On Sat, Jun 14, 2014, at 15:39, Nikolaus Rath wrote:
>>> It seems to me that a much cleaner solution would be to simply declare
>>> _pyio's readinto to only work wi
Hello,
The _pyio.BufferedIOBase class contains the following hack to make sure
that you can read-into array objects with format 'b':
try:
b[:n] = data
except TypeError as err:
import array
if not isinstance(b, array.array):
raise
Benjamin Peterson writes:
> On Thu, Jun 12, 2014, at 18:06, Nikolaus Rath wrote:
>> Consider this simple example:
>>
>> $ cat test.py
>> import io
>> import warnings
>>
>> class StridedStream(io.IOBase):
>> def __init__
"R. David Murray" writes:
> Also notice that using a list with shell=True is using the API
> incorrectly. It wouldn't even work on Linux, so that torpedoes
> the cross-platform concern already :)
>
> This kind of confusion is why I opened http://bugs.python.org/issue7839.
Can someone describe an
Benjamin Peterson writes:
> On Wed, Jun 11, 2014, at 17:11, Nikolaus Rath wrote:
>> MRAB writes:
>> > On 2014-06-11 02:30, Nikolaus Rath wrote:
>> >> Hello,
>> >>
>> >> I recently noticed (after some rather protacted debugging) that the
&g
MRAB writes:
> On 2014-06-11 02:30, Nikolaus Rath wrote:
>> Hello,
>>
>> I recently noticed (after some rather protacted debugging) that the
>> io.IOBase class comes with a destructor that calls self.close():
>>
>> [0] nikratio@vostro:~/tmp$ cat test
Hello,
I recently noticed (after some rather protacted debugging) that the
io.IOBase class comes with a destructor that calls self.close():
[0] nikratio@vostro:~/tmp$ cat test.py
import io
class Foo(io.IOBase):
def close(self):
print('close called')
r = Foo()
del r
[0] nikratio@vostro
Nathaniel Smith writes:
>> > tmp1 = a + b
>> > tmp1 += c
>> > tmp1 /= c
>> > result = tmp1
>>
>> Could this transformation be done in the ast? And would that help?
>
> I don't think it could be done in the ast because I don't think you can
> work with anonymous temporaries there. B
Nathaniel Smith writes:
> Such optimizations are important enough that numpy operations always
> give the option of explicitly specifying the output array (like
> in-place operators but more general and with clumsier syntax). Here's
> an example small-array benchmark that IIUC uses Jacobi iteratio
Hello,
While my last appeal resulted in quite some commits (thanks!), I still
have some more commit-ready patches waiting for review. It'd be great
if some people could find time to take a look:
* http://bugs.python.org/issue1738 (filecmp.dircmp does exact match
only)
Reviewed patch, reba
Hello,
I've just run the testsuite of hg tip with
./python -m test -u network,urlfetch -j 8 -G -v
and it finished with
,
| [...]
| test_extract_dir (test.test_zipfile.TestWithDirectory) ... ok
| test_store_dir (test.test_zipfile.TestWithDirectory) ... ok
| test_different_file (test.test_zip
Hello,
I was surprised to find the following in bytesobject.c:
,
| [...]
|As always, an extra byte is allocated for a trailing \0 byte (newsize
|does *not* include that), and a trailing \0 byte is stored.
| */
|
| int
| _PyBytes_Resize(PyObject **pv, Py_ssize_t newsize)
| {
| [...]
|
Antoine Pitrou writes:
> On Sun, 27 Apr 2014 12:10:46 -0700
> Nikolaus Rath wrote:
>>
>> * http://bugs.python.org/issue20951 (SSLSocket.send() returns 0 for
>> non-blocking socket)
>>
>> In this case someone just needs to decide if we want to (a) do
Hello,
While my last appeal resulted in quite some commits (thanks!), I still
have some more commit-ready patches waiting for review. It'd be great
if some people could find time to take a look:
* http://bugs.python.org/issue1738 (filecmp.dircmp does exact match
only)
* http://bugs.python.org
"Martin v. Löwis" writes:
> Am 13.04.14 08:36, schrieb Stephen J. Turnbull:
>
>> I admit the tone was biased toward nagging or "blaming the victim",
>> and again I apologize for causing misunderstanding. Nikolaus isn't
>> "wrong" for posting here. My claim is that in current circumstances,
>> co
"Stephen J. Turnbull" writes:
> I apologize for the tone. I need to go *right* now, and can't fix
> that. Really, I'm sympathetic and my goal is not just to defend
> python-dev, but to help you get the reviews your work deserves.
> Please read with that in mind.
Will do - but why the rush? Be a
Terry Reedy writes:
[Quote conveniently rearranged]
>> I've accumulated a number of patches in the issue tracker that are
>> waiting for someone to review/commit/reject them. I'm eager to make
>> corrections as necessary, I just need someone to look the work that I've
>> done so far:
>
> Do you co
Hello,
I've accumulated a number of patches in the issue tracker that are
waiting for someone to review/commit/reject them. I'm eager to make
corrections as necessary, I just need someone to look the work that I've
done so far:
* http://bugs.python.org/issue20951 (SSLSocket.send() returns 0 for
Hello,
The BufferedReader (and BufferedRWPair) classes both have a read1()
method in addition to the regular read() method to bypass the internal
buffer. This is quite useful if you need to do some buffered reading
(e.g. to parse a header) followed by a lot of bulk data that you want to
process as
Chris Angelico writes:
> On Wed, Mar 26, 2014 at 11:54 AM, Nikolaus Rath wrote:
>> 2. Change the behavior immediately, potentially breaking some
>>applications that worked around it, but unbreaking others that relied
>>on the documented behavior.
>
> If it'
Hello,
I'd like to hear some more opinions on
http://bugs.python.org/issue20951. I think the possible courses of
action are:
1. Document the current behavior.
This has the drawback that (a) it still remains rather
counterintuitive, and (b) one still needs extra code to distinguish
betwe
Nick Coghlan writes:
> Maintainability
> ---
>
> This policy does NOT represent a commitment by volunteer contributors to
> actually backport network security related changes from the Python 3 series
> to the Python 2 series. Rather, it is intended to send a clear signal to
> potential
Charles-François Natali writes:
> 2014-03-15 21:44 GMT+00:00 Nikolaus Rath :
>
>> Guido van Rossum writes:
>> > This downside of using subclassing as an API should be well known by now
>> > and widely warned against.
>>
>> It wasn't known to me u
Guido van Rossum writes:
> This downside of using subclassing as an API should be well known by now
> and widely warned against.
It wasn't known to me until now. Are these downsides described in some
more detail somewhere?
So far I have always thought that, as long as I avoid using private
attr
Tres Seaver writes:
> On 03/12/2014 04:49 PM, Chris Angelico wrote:
>> You can use hasattr() in place of AttributeError
>
> I use:
>
> getattr(subject, attrname, default)?
>
> *all the time*.
In my opinion that's almost as ugly, because it still forces you to
specify the attribute name as a stri
Ethan Furman writes:
> Example::
>
>>>> b'%4x' % 10
>b' a'
>
>>>> '%#4x' % 10
>' 0xa'
>
>>>> '%04X' % 10
>'000A'
Shouldn't the second two examples also be bytes, ie. b'%#4x' instead of
'%#4x'?
Best,
-Nikolaus
--
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8
"Stephen J. Turnbull" writes:
> Ethan Furman writes:
> > On 02/21/2014 07:46 PM, Chris Angelico wrote:
> > >
> > > but not this:
> > >
> > > value = expr except Exception: default except Exception: default
> >
> > This should be the way it works. Nothing is gained in readability
> > by t
Larry Hastings writes:
> In the second attempt, the signature looked like this:
>
>sig=(arguments)\n
>
[...]
> This all has caused no problems so far. But my panicky email last
> night was me realizing a problem we may see down the road. To recap:
> if a programmer writes a module using the
Larry Hastings writes:
> All is not lost! What follows is rough pseudo-C code, hopefully you
> can take it from here.
>
>typedef struct {
> int set;
> time_t when;
>} clinic_time_t;
>
>#define DEFAULT_CLINIC_TIME_T {0, 0}
>
>static int
>parse_clinic_time_t_arg(PyOb
Larry Hastings writes:
> A comment on your approach so far: I'm very much against giving
> "default" a default value in the constructor.
You mean in the definition of the custom converter class?
> I realize that hack saves you having to say "= NULL" in a lot of
> places. But explicit is better
Serhiy Storchaka writes:
> 20.01.14 06:19, Nikolaus Rath написав(ла):
>> This works if the user calls time.gmtime(None), but it fails for
>> time.gmtime(). It seems that in that case my C converter function is
>> never called.
>>
>> What's the trick
review my patch.
Best,
-Nikolaus
> [1] If you set a default value, or put it in brackets as Serhiy later
> recommends, it works the same.
>
>
> On Sun, Jan 19, 2014 at 8:19 PM, Nikolaus Rath wrote:
>
>> Larry Hastings writes:
>> > On 01/18/2014 09:52 PM, Ryan Smit
Larry Hastings writes:
> On 01/18/2014 09:52 PM, Ryan Smith-Roberts wrote:
>>
>> I still advise you not to use this solution. time() is a system call
>> on many operating systems, and so it can be a heavier operation than
>> you'd think. Best to avoid it unless it's needed (on FreeBSD it
>> seems
Larry Hastings writes:
> On 01/18/2014 09:52 PM, Ryan Smith-Roberts wrote:
>>
>> I still advise you not to use this solution. time() is a system call
>> on many operating systems, and so it can be a heavier operation than
>> you'd think. Best to avoid it unless it's needed (on FreeBSD it
>> seems
;seconds) == -1)
return NULL;
}
return time_localtime_impl(self, seconds);
}
Apart from getting an error from clinic.py, it seems to me that this
should in principle be possible.
Best,
Nikolaus
>
> So, the best idea is to
>
> * Remove the PyArgs_ParseTuple c
Hello,
I'm trying to convert functions using parse_time_t_args() (from
timemodule.c) for argument parsing to argument clinic.
The function is defined as:
,
| static int
| parse_time_t_args(PyObject *args, char *format, time_t *pwhen)
| {
| PyObject *ot = NULL;
| time_t whent;
|
|
Ethan Furman writes:
> Nikolaus,
>
> Good write-up. Please submit it to the bug tracker:
> http://bugs.python.org
Submitted as http://bugs.python.org/issue19414.
If someone gives me the go-ahead for one of the proposed solutions, I'd
be happy to create a full patch.
Best,
Nikolaus
--
Encrypt
Hello,
The documentation says the following about modifying a dict while
iterating through its view:
| Iterating views while adding or deleting entries in the dictionary may
| raise a RuntimeError or fail to iterate over all entries.
(http://docs.python.org/3/library/stdtypes.html#dict-views)
Th
Guido van Rossum writes:
>> 1. Having to enter the values is annoying. Sorry, I read the rationale and
>> all that, and I *still* want to write a C-Like enum { A, B, C }. I fully
>> expect to edit and reorder enums (if I ever use them) and get irritated with
>> having to update the value assignmen
Armin Rigo writes:
> Hi Jeff,
>
> On Mon, Apr 29, 2013 at 11:58 PM, Jeff Allen <"ja...py"@farowl.co.uk> wrote:
>> In Jython, (...)
>
> Thanks Jeff for pointing this out. Jython thus uses a custom
> mechanism similar to PyPy's, which is also similar to atexit's. It
> should not be too hard to imp
On 04/30/2013 07:05 PM, Nikolaus Rath wrote:
> Larry Hastings writes:
>> On 04/29/2013 07:42 PM, Nikolaus Rath wrote:
>>> State is a class, it just inherits from enum. Thus:
>>>
>>> type(State) == type(enum) == type(EnumMetaclass)
>>> issubclass(Sta
Larry Hastings writes:
> On 04/29/2013 07:42 PM, Nikolaus Rath wrote:
>> State is a class, it just inherits from enum. Thus:
>>
>> type(State) == type(enum) == type(EnumMetaclass)
>> issubclass(State, enum) == True
>>
>>
>> HTH,
>>
>>
Marco Hemmelrath writes:
> class State(enum):
> idle = 0
> busy = 1
> idling = idle
> ideling = 0
>
> together with the premises:
>
> 1. type(State.busy) == State
> 2. type(State) == enum
State is a class, it just inherits from enum. Thus:
type(State)
Armin Rigo writes:
> Hi Nikolaus,
>
> On Sat, Apr 27, 2013 at 4:39 AM, Nikolaus Rath wrote:
>> It's indeed very informative, but it doesn't fully address the question
>> because of the _pyio module which certainly can't use any custom C code.
>
Guido van Rossum writes:
> On Sat, Apr 27, 2013 at 10:04 AM, Ethan Furman wrote:
>> While this will certainly work, it means you can't have class variables that
>> happen to be the same type as the enum -- so no int in an IntEnum, for
>> example.
>>
>> The solution I like best is the helper class
Steven D'Aprano writes:
> I'm sorry, but all these suggestions are getting the API completely
> backwards by making the common case harder than the rare case.
>
> We're creating an Enum, right? So the *common case* is to populate it
> with enum values. 99% of the time, enumerated values will be al
Steven D'Aprano writes:
> On 26/04/13 13:22, Greg wrote:
>> On 26/04/2013 3:12 p.m., Glenn Linderman wrote:
>>> On 4/25/2013 7:49 PM, Nick Coghlan wrote:
>>
You couldn't create an enum of callables, but that would be a
seriously weird thing to do anyway
>>>
>>> But aren't all classes
1 - 100 of 103 matches
Mail list logo
